Subject: Client-Cert Header draft

From: Brian Campbell <[email-masked]>
Date: Wed, 15 Apr 2020 15:01:13 -0600

Hello HTTP Working Group,

I've somewhat inadvertently found myself working on this draft
https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/,
which aspires to define a "Client-Cert" HTTP header field that allows a TLS
terminating reverse proxy to convey information about the client
certificate of a mutually-authenticated TLS connection to an origin server
in a common and predictable manner.

I presented the concept
<https://datatracker.ietf.org/meeting/107/materials/slides-107-secdispatch-client-cert-http-header-00>
at the recent virtual IETF 107 secdispatch meeting
<https://datatracker.ietf.org/meeting/107/materials/minutes-107-secdispatch-00>
and the outcome from that was basically that there seems to be some
interest in pursuing the work and the suggestion that the conversation be
taken to the HTTPbis WG (and also keep TLS WG involved - presumably if the
work progresses). And that's what brings me here. I also hope to get a
little bit of time at one of the upcoming virtual interims to
present/discuss the draft.

Thanks,
Brian

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Mike Bishop <[email-masked]>
Date: Fri, 17 Apr 2020 19:20:12 +0000

Despite the distaste for client certificates from some quarters, they are still both used and useful.  I’m certainly interested in seeing this progress.

In today’s situation, the intermediary checks that the cert matches the rules it has been given to authenticate clients, and only forwards the requests from valid clients.  Arguably, the origin is offloading less trust in this draft’s model – the intermediary is responsible for validating that the client possesses the claimed certificate, but might leave the origin to decide what scope of access the certificate actually grants.  That allows finer-grained access control, but also allows greater ability to send requests back to the origin.  It also opens the door for intermediaries which don’t support this header to accidentally forward requests containing it.  Requiring intermediaries to drop it doesn’t get you much, since only those intermediaries aware of the spec will comply by dropping the header.  To help address these, I’d like to see this mix in something that the intermediary holds and the client doesn’t, such as an exporter from its TLS connection to the server.

But all that is refinement – the core concept here is beneficial, and I’d like to see more engagement here.

From: Brian Campbell <[email-masked]>
Sent: Wednesday, April 15, 2020 5:01 PM
To: HTTP Working Group <[email-masked]>
Subject: Client-Cert Header draft

I've somewhat inadvertently found myself working on this draft https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/, which aspires to define a "Client-Cert" HTTP header field that allows a TLS terminating reverse proxy to convey information about the client certificate of a mutually-authenticated TLS connection to an origin server in a common and predictable manner.

I presented the concept<https://datatracker.ietf.org/meeting/107/materials/slides-107-secdispatch-client-cert-http-header-00> at the recent virtual IETF 107 secdispatch meeting<https://datatracker.ietf.org/meeting/107/materials/minutes-107-secdispatch-00> and the outcome from that was basically that there seems to be some interest in pursuing the work and the suggestion that the conversation be taken to the HTTPbis WG (and also keep TLS WG involved - presumably if the work progresses). And that's what brings me here. I also hope to get a little bit of time at one of the upcoming virtual interims to present/discuss the draft.

Thanks,
Brian

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 17 Apr 2020 20:28:39 +0100

+1 to everything Mike said

On Fri, 17 Apr 2020, 20:24 Mike Bishop, <[email-masked]> wrote:

> Despite the distaste for client certificates from some quarters, they are
> still both used and useful.  I’m certainly interested in seeing this
> progress.
>
>
>
> In today’s situation, the intermediary checks that the cert matches the
> rules it has been given to authenticate clients, and only forwards the
> requests from valid clients.  Arguably, the origin is offloading less trust
> in this draft’s model – the intermediary is responsible for validating that
> the client possesses the claimed certificate, but might leave the origin to
> decide what scope of access the certificate actually grants.  That allows
> finer-grained access control, but also allows greater ability to send
> requests back to the origin.  It also opens the door for intermediaries
> which don’t support this header to accidentally forward requests containing
> it.  Requiring intermediaries to drop it doesn’t get you much, since only
> those intermediaries aware of the spec will comply by dropping the header.
> To help address these, I’d like to see this mix in something that the
> intermediary holds and the client doesn’t, such as an exporter from its TLS
> connection to the server.
>
>
>
> *From:* Brian Campbell <[email-masked]>
> *Sent:* Wednesday, April 15, 2020 5:01 PM
> *To:* HTTP Working Group <[email-masked]>
> *Subject:* Client-Cert Header draft
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 17 Apr 2020 16:58:40 -0400

+1 for seeing this adopted and progressing within this group. This is a simple thing that different developers have had to solve for decades and each has solved it in trivially different ways. I would love to see one commonly-accepted way to do this.

TLS terminators aren’t going away any time soon, so I think we should make them at least a bit more manageable. 

 — Justin

> On Apr 15, 2020, at 5:01 PM, Brian Campbell <[email-masked]> wrote:
> 
> I've somewhat inadvertently found myself working on this draft https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/ <https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/>, which aspires to define a "Client-Cert" HTTP header field that allows a TLS terminating reverse proxy to convey information about the client certificate of a mutually-authenticated TLS connection to an origin server in a common and predictable manner.
> 
> I presented the concept <https://datatracker.ietf.org/meeting/107/materials/slides-107-secdispatch-client-cert-http-header-00> at the recent virtual IETF 107 secdispatch meeting <https://datatracker.ietf.org/meeting/107/materials/minutes-107-secdispatch-00> and the outcome from that was basically that there seems to be some interest in pursuing the work and the suggestion that the conversation be taken to the HTTPbis WG (and also keep TLS WG involved - presumably if the work progresses). And that's what brings me here. I also hope to get a little bit of time at one of the upcoming virtual interims to present/discuss the draft.
> 
> Thanks,
> Brian 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>

---

From: David Benjamin <[email-masked]>
Date: Fri, 17 Apr 2020 17:11:46 -0400

This draft isn't sufficient to properly move the access checks out of the
TLS terminator. More care is needed here. There is a "distaste for client
certificates from some quarters" for a reason.

In general, connection-level authentication does not play well with HTTP.
Server identities are generally public, so there is no complex policy
around when to release them. Client identities are generally user
identities and thus sensitive, with local policies, usually involving user
prompts and selections. That interacts badly with client certificates. It
just barely works today, but moving individual components without thought
as to the overall picture will break it.

In particular, client HTTP stacks necessarily cache client certificate
decisions. Without caching, the user is potentially prompted on every HTTP
request, but a user session involves many HTTP requests. Additionally, the
decision is inherently cached by way of connection reuse and session
resumption optimizations. Short of forcing a full TLS handshake on every
HTTP request, clients could not prompt on every HTTP request if they wanted
to. That means the HTTP stacks need an explicit signal, or no amount of
reloads will allow the user to select a different identity.

Currently, the only signal for a bad client certificate is a fatal TLS
alert. If the access checks are moved, bad client certificate signals will
come out of the origin server, which cannot generate those. This draft may
need to define a suitable HTTP 4xx code to correspond with TLS client
certificate authentication. Of course, existing clients won't know to
process that, but perhaps the origin server should translate to a TLS
alert? But then the response is never delivered, which may be differently
odd. Then one must consider the interaction with HTTP/2, which multiplexes
streams and potentially multiple origins together.

There may be further problems here that I haven't thought through. The
suggestion of this enabling finer-grained access control worries me.

---

From: "Soni L." <[email-masked]>
Date: Fri, 17 Apr 2020 18:24:03 -0300

if I may, I'd like to suggest a websocket-like mechanism that's 
initiated by TLS terminators.

if the TLS terminator thinks a request needs to reach the server, it can 
let the client request directly from the server that way, including 
client certs and whatnot. if done right, this would also allow 
protection of other sensitive user data (e.g. direct messages) from the 
TLS terminator.

On 2020-04-17 5:58 p.m., Justin Richer wrote:
> +1 for seeing this adopted and progressing within this group. This is 
> a simple thing that different developers have had to solve for decades 
> and each has solved it in trivially different ways. I would love to 
> see one commonly-accepted way to do this.
>
> TLS terminators aren’t going away any time soon, so I think we should 
> make them at least a bit more manageable.
>
>  — Justin
>
>> On Apr 15, 2020, at 5:01 PM, Brian Campbell 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> which aspires to define a "Client-Cert" HTTP header field that allows 
>> a TLS terminating reverse proxy to convey information about the 
>> client certificate of a mutually-authenticated TLS connection to an 
>> origin server in a common and predictable manner.
>>
>> I presented the concept 
>> interest in pursuing the work and the suggestion that the 
>> conversation be taken to the HTTPbis WG (and also keep TLS WG 
>> involved - presumably if the work progresses). And that's what brings 
>> me here. I also hope to get a little bit of time at one of the 
>> upcoming virtual interims to present/discuss the draft.
>>
>> Thanks,
>> Brian
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> /CONFIDENTIALITY NOTICE: This email may contain confidential and 
>> privileged material for the sole use of the intended recipient(s). 
>> Any review, use, distribution or disclosure by others is strictly 
>> prohibited..  If you have received this communication in error, 
>> please notify the sender immediately by e-mail and delete the message 
>> and any file attachments from your computer. Thank you./
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 17 Apr 2020 15:30:24 -0700

> connection to the server.

I'm sure unsurprisingly to nobody, I second Mike's comments here.

-Ekr

---

From: Brian Campbell <[email-masked]>
Date: Mon, 20 Apr 2020 15:52:34 -0600

Indeed, it is unsurprising to me.

But I do acknowledge the opinion expressed by Mike and +1'd by you and
Lucas.

While header sanitization can be deployed securely, there are ways to do it
wrong and admittedly things don't "fail safe" when that happens. It would
be nice to simply point to a more generic solution for something better,
but I think we've previously demonstrated that there is not enough energy
from parties interested in pursuing it. Lacking that something more
generic, I personally (still) think it would be rather
awkward/inappropriate to have this draft define a one-off solution. But
that is my opinion as an individual and it would clearly be a topic for
further discussion should this draft become a WG item.

---

From: Brian Campbell <[email-masked]>
Date: Mon, 20 Apr 2020 16:14:16 -0600

Very true that connection-level authentication doesn't always play well
with HTTP. But the intended scope of this draft isn't trying to address
that. It's only trying to bring some commonality to what's typically done
in practice now. I would think an HTTP 403 or even application level
controls on content is what's happening now regardless. The approach in
this draft does mean that authorization errors aren't going to be conveyed
back to the client at the connection level but, as you point out, doing so
is differently odd. So much so that I don't think the draft needs to do
anything to facilitate it.

On Fri, Apr 17, 2020 at 3:12 PM David Benjamin <[email-masked]>
wrote:

>>> Despite the distaste for client certificates from some quarters, they
>>> are still both used and useful.  I’m certainly interested in seeing this
>>> progress.
>>>
>>>
>>>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 20 Apr 2020 16:20:55 -0600

That's really quite different than the intended scope of the draft, which
was/is a reverse proxy that's terminating TLS (from the client's
perspective anyway) and taking HTTP with the backend.

On Fri, Apr 17, 2020 at 3:25 PM Soni L. <[email-masked]> wrote:

> if I may, I'd like to suggest a websocket-like mechanism that's initiated
> by TLS terminators.
>
> let the client request directly from the server that way, including client
> certs and whatnot. if done right, this would also allow protection of other
> sensitive user data (e.g. direct messages) from the TLS terminator.
>
> +1 for seeing this adopted and progressing within this group. This is a
> simple thing that different developers have had to solve for decades and
> each has solved it in trivially different ways. I would love to see one
> commonly-accepted way to do this.
>

---

From: "Soni L." <[email-masked]>
Date: Mon, 20 Apr 2020 19:26:48 -0300

you'd still have a reverse proxy that's terminating TLS and talking HTTP 
with the backend.

you'd just also have a way for that reverse proxy to pass a raw TLS 
stream through, so the client can talk HTTPS with the backend when 
needed. it'd still be in the middle of the connection and fully capable 
of terminating it if it detects potentially abusive behaviour.

On 2020-04-20 7:20 p.m., Brian Campbell wrote:
> That's really quite different than the intended scope of the draft, 
> which was/is a reverse proxy that's terminating TLS (from the client's 
> On Fri, Apr 17, 2020 at 3:25 PM Soni L. <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     if the TLS terminator thinks a request needs to reach the server,
>     it can let the client request directly from the server that way,
>     including client certs and whatnot. if done right, this would also
>     allow protection of other sensitive user data (e.g. direct
>     messages) from the TLS terminator.
>
>>     +1 for seeing this adopted and progressing within this group.
>>     This is a simple thing that different developers have had to
>>     solve for decades and each has solved it in trivially different
>>     ways. I would love to see one commonly-accepted way to do this.
>>
>>     TLS terminators aren’t going away any time soon, so I think we
>>     should make them at least a bit more manageable.
>>
>>      — Justin
>>
>>>     which aspires to define a "Client-Cert" HTTP header field that
>>>     allows a TLS terminating reverse proxy to convey information
>>>     about the client certificate of a mutually-authenticated TLS
>>>     connection to an origin server in a common and predictable manner.
>>>
>>>     I presented the concept
>>>     and the outcome from that was basically that there seems to be
>>>     some interest in pursuing the work and the suggestion that the
>>>     involved - presumably if the work progresses). And that's what
>>>     brings me here. I also hope to get a little bit of time at one
>>>     of the upcoming virtual interims to present/discuss the draft.
>>>
>>>     Thanks,
>>>     Brian
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>     privileged material for the sole use of the intended
>>>     recipient(s). Any review, use, distribution or disclosure by
>>>     others is strictly prohibited..  If you have received this
>>>     communication in error, please notify the sender immediately by
>>>     e-mail and delete the message and any file attachments from your
>>>     computer. Thank you./
>>
>
>
> review, use, distribution or disclosure by others is strictly 
> prohibited.  If you have received this communication in error, please 
> notify the sender immediately by e-mail and delete the message and any 
> file attachments from your computer. Thank you./

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 20 Apr 2020 23:59:14 +0100

Hey,

On Mon, Apr 20, 2020 at 11:28 PM Soni L. <[email-masked]> wrote:

> you'd just also have a way for that reverse proxy to pass a raw TLS stream
> through, so the client can talk HTTPS with the backend when needed. it'd
> still be in the middle of the connection and fully capable of terminating
> it if it detects potentially abusive behaviour.
>
> I'm with Brian on this; CDN/reverse proxies provide an offload of HTTP
processing from the origin that brings advantages such as performance,
scale, and security. Although it could be technically possible to pass
through TLS (pretty much covered by CONNECT already), the concept negates
the value proposition of a CDN architecture. I think Brian's document has
more value with the scope that he has described.

Cheers
Lucas

---

From: "Soni L." <[email-masked]>
Date: Mon, 20 Apr 2020 20:10:31 -0300

the CDN would have to consent to the client interacting with the server, 
thus not affecting performance, scale and security, and it'd only be for 
non-CDN-safe resources such as private content anyway.

On 2020-04-20 7:59 p.m., Lucas Pardue wrote:
> Hey,
>
> On Mon, Apr 20, 2020 at 11:28 PM Soni L. <[email-masked] 
>     you'd still have a reverse proxy that's terminating TLS and
>     talking HTTP with the backend.
>
>     you'd just also have a way for that reverse proxy to pass a raw
>     TLS stream through, so the client can talk HTTPS with the backend
>     when needed. it'd still be in the middle of the connection and
>     fully capable of terminating it if it detects potentially abusive
>     behaviour.
>
>>     That's really quite different than the intended scope of the
>>     draft, which was/is a reverse proxy that's terminating TLS (from
>>     the client's perspective anyway) and taking HTTP with the backend.
>>
> through TLS (pretty much covered by CONNECT already), the concept 
> negates the value proposition of a CDN architecture. I think Brian's 
> document has more value with the scope that he has described.
>
> Cheers
> Lucas
>
>

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 21 Apr 2020 00:44:01 +0100

> non-CDN-safe resources such as private content anyway.
The CDN provides those features for the origin. That's the purpose.
Allowing clients direct access to the origin means that the origin has to
duplicate the functions a CDN provides or not have them at all. I don't
think that's what people are asking for, particularly people that are happy
to delegate their TLS termination as happens today. What I am aware of is a
desire to understand a property of the TLS connection, just like wanting to
see the negotiated ALPN ID, ciphersuite, client IP address etc. for the
purposes of auditing, analysis or some application logic.

Plus, what you're describing requires a client that is savvy enough to
understand content and the distribution architecture of deployments in
order to decide when to punch through the CDN. That becomes fragile very
quickly.

---

From: "Soni L." <[email-masked]>
Date: Mon, 20 Apr 2020 21:24:16 -0300

easy: the client can only punch through the CDN with a bearer token.

On 2020-04-20 8:44 p.m., Lucas Pardue wrote:
>
> On Tue, Apr 21, 2020 at 12:10 AM Soni L. <[email-masked] 
>     the CDN would have to consent to the client interacting with the
>     server, thus not affecting performance, scale and security, and
>     it'd only be for non-CDN-safe resources such as private content
>     anyway.
>
> Allowing clients direct access to the origin means that the origin has 
> to duplicate the functions a CDN provides or not have them at all. I 
> don't think that's what people are asking for, particularly people 
> that are happy to delegate their TLS termination as happens today. 
> What I am aware of is a desire to understand a property of the TLS 
> connection, just like wanting to see the negotiated ALPN ID, 
> ciphersuite, client IP address etc. for the purposes of auditing, 
> analysis or some application logic.
>
> order to decide when to punch through the CDN. That becomes fragile 
> very quickly.
>

---

From: Roberto Polli <[email-masked]>
Date: Tue, 21 Apr 2020 18:30:57 +0200

Hi Brian,

I think the work is interesting and useful, though it has complexities.

TL;DR: I'd only standardize the header semantic and file a detailed
Security Considerations
section with different sections addressing the different issues.

More follows:

1- standardizing the header name is good;
2- it is correct to investigate the impacts of this header when the
network topology is not trivial
    ( I see use cases for TTRP + re-encryption). I suggest providing subsections
    in the Security Considerations;
3- the only reason for trusting that header is an actual agreement
between the owners
    of the services: I am not sure we should detail things like `Use
of the technique is to be a configuration or deployment`
    but please provide your thoughts;
4- I am not sure that adding processing rules in the spec can provide more
    guarantees to the backend server,  as it's completely "delegating
the authentication"
    to the upstream server and cannot verify the received information.

My2c,
R.

Il giorno gio 16 apr 2020 alle ore 10:05 Brian Campbell
<[email-masked]> ha scritto:
> I presented the concept at the recent virtual IETF 107 secdispatch meeting and the outcome from that was basically that there seems to be some interest in pursuing the work and the suggestion that the conversation be taken to the HTTPbis WG (and also keep TLS WG involved - presumably if the work progresses). And that's what brings me here. I also hope to get a little bit of time at one of the upcoming virtual interims to present/discuss the draft.
>
> Thanks,
> Brian
>
>
>
>
>
>
>
>
>
>
>

---

From: David Benjamin <[email-masked]>
Date: Tue, 21 Apr 2020 16:13:22 -0400

HTTP 403 and especially application level controls do not work. While some
misconfigured servers do report the error outside TLS, they are
misconfiguration. As a client, we consider this scenario unsupported. The
poor caching behavior is on the server operator, as the defined mechanism
for reporting a TLS client certificate error, namely a TLS alert, was not
used.

We should not standardize a misconfiguration. Wanting to separate TLS
termination from access control is plausible, but any attempt to solve this
problem must be done holistically. This includes defining error-handling
and making sure it actually works.

On Mon, Apr 20, 2020 at 6:14 PM Brian Campbell <[email-masked]>
wrote:

> review, use, distribution or disclosure by others is strictly prohibited.

---

From: Graham Leggett <[email-masked]>
Date: Wed, 22 Apr 2020 00:17:17 +0200

> I've somewhat inadvertently found myself working on this draft https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/ <https://datatracker.ietf.org/doc/draft-bdc-something-some…

Big +1 for this.

I added JWT support to Apache httpd/apr in an effort to solve this problem, having one single header would be vastly simpler.

> I presented the concept <https://datatracker.ietf.org/meeting/107/materials/slides-107-secdispatch-client-cert-http-header-00> at the recent virtual IETF 107 secdispatch meeting <https://datatracke…

Having read the draft, one thing I would suggest is that the ability exists for the contents of the Client-Cert header to be signed, so that anyone who cares can verify that the header came from where it said it came from.

To simplify this even further, if the Client-Cert header was signed by the private key of the certificate of the server that terminated the request, a lot of complexity around figuring out the origin of the header evaporates. (I wouldn’t make this a MUST requirement, but maybe RECOMMENDED perhaps).

As an optional one step further I personally would then connect the terminating reverse proxy and the backend with a client certificate connection using the TTRP reverse proxy’s certificate. The backend can then verify the client certificate (the TTRP cert) as being expected, then verify that the Client-Cert header was signed with the TTRP certificate. If this checks out, and we trust the TTRP as having not been tampered with, we have a strong path.

"A certificate is represented in text as an "EncodedCertificate",
   which is the base64-encoded (Section 4 of [RFC4648]) DER [ITU.X690]
   PKIX certificate.”

To do this the payload of the Client-Cert header would be a base64 of a DER encoded RFC5652 CMS/PKCS7. The payload would be the DER encoded X509 client certificate, and the CMS would be the signed envelope.

Regards,
Graham
—

---

From: James <[email-masked]>
Date: Wed, 22 Apr 2020 13:56:34 +0100

On 21/04/2020 23:17, Graham Leggett wrote:
> Having read the draft, one thing I would suggest is that the ability 
> exists for the contents of the Client-Cert header to be signed, so that 
> anyone who cares can verify that the header came from where it said it 
> came from ... (I wouldn’t make this a MUST requirement, but maybe  > RECOMMENDED perhaps).

+1 for it not being a MUST as I think that signing the header should 
only be RECOMMENDED or SHOULD be present when the TRRP to Origin 
connection is NOT using TLS itself. Perhaps this could be offered as a 
separate header itself. The draft appears to focus around no TLS being 
used from TRRP to Origin, I have uses cases where it exists - such as a 
publicly trusted CA used on the TRRP's server certificate, but an 
internal CA used to the Origin.

- J

---

From: Brian Campbell <[email-masked]>
Date: Fri, 24 Apr 2020 15:21:20 -0600

Apologies for the slow reply.

> I think the work is interesting and useful, though it has complexities.

Thank you and yes.

> section with different sections addressing the different issues.

I sorta think that's how the draft currently lays out, more or less, so I'm
not sure what to take away from the comment.

>     in the Security Considerations;

I've endeavored to stay agnostic to the topology to the extent possible.
Other than to say it's applicable to an HTTPS reverse proxy and whatever
encompass the backend needs to be secured. The prospect of TTRP +
re-encryption is mentioned in the draft. But not mandated. This seems like
the appropriate scope to me.

>     but please provide your thoughts;

The "configuration or deployment" phrasing was intended to convey the need
for some such agreement (including that the owners could be the same
entity) as a prerequisite to doing this whole thing so it's an opt-in bit
of functionality on both servers. I think we are saying the same thing. But
I'm certainly open to additional or alternative text to say as much.

>     to the upstream server and cannot verify the received information.

If I understand, I believe that is inline with my intent in the current
draft (noting that there've been some comments/requests for it to be
different), which was that the backend server doesn't itself verify the
received information but takes it at the word of the upstream server.

> > I presented the concept at the recent virtual IETF 107 secdispatch
> meeting and the outcome from that was basically that there seems to be some
> > CONFIDENTIALITY NOTICE: This email may contain confidential and
> your computer. Thank you.
>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 24 Apr 2020 15:33:14 -0600

Apologies for the slow reply. And thanks for the support of the idea and
suggestions. At this point, while this is still just an unadopted
individual draft, I think I'd categorize the suggestion as another voice of
support for something more to be done directly with respect to protecting
the header from injection. Using the server certificate and an asymmetric
signature is an approach to that (which I admittedly hadn't thought much
about) which would have its pros and cons.

On Tue, Apr 21, 2020 at 4:17 PM Graham Leggett <[email-masked]> wrote:

> I added JWT support to Apache httpd/apr in an effort to solve this
> problem, having one single header would be vastly simpler.
>
> I presented the concept
> anyone who cares can verify that the header came from where it said it came
> from.
>
> To simplify this even further, if the Client-Cert header was signed by the
> private key of the certificate of the server that terminated the request, a
> lot of complexity around figuring out the origin of the header evaporates.
> (I wouldn’t make this a MUST requirement, but maybe RECOMMENDED perhaps).
>
> As an optional one step further I personally would then connect the
> terminating reverse proxy and the backend with a client certificate
> connection using the TTRP reverse proxy’s certificate. The backend can then
> verify the client certificate (the TTRP cert) as being expected, then
> verify that the Client-Cert header was signed with the TTRP certificate. If
> this checks out, and we trust the TTRP as having not been tampered with, we
> have a strong path.
>
> To do this the payload of the Client-Cert header would be a base64 of a
> DER encoded RFC5652 CMS/PKCS7. The payload would be the DER encoded X509
> client certificate, and the CMS would be the signed envelope.
>
> Regards,
> Graham
> —
>
>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 24 Apr 2020 16:13:53 -0600

The draft is trying to be agnostic to things like TLS being used from TRRP
to Origin or not. But certainly doesn't rule it out. The intro has
"...HTTPS is also usually employed between the proxy and the origin
server...".

---

From: Brian Campbell <[email-masked]>
Date: Fri, 24 Apr 2020 16:19:59 -0600

Rather than misconfiguration, I would characterize it as an impedance
mismatch in functionality and expectations that arises at the intersection
of making use of TLS-level authentication at the HTTP level. With that
being said, I suspect this is something we just see differently and that's
unlikely to change. But I do note the objection and it's something that can
be hashed out further by the WG, if the work on the document proceeds in
the WG.

On Tue, Apr 21, 2020 at 2:13 PM David Benjamin <[email-masked]>
wrote:

>>> This draft isn't sufficient to properly move the access checks out of
>>> the TLS terminator. More care is needed here. There is a "distaste for
>>> client certificates from some quarters" for a reason.
>>>
>>> In general, connection-level authentication does not play well with
>>> HTTP. Server identities are generally public, so there is no complex policy
>>>>> In today’s situation, the intermediary checks that the cert matches
>>>>> the rules it has been given to authenticate clients, and only forwards the

---

From: Graham Leggett <[email-masked]>
Date: Sat, 25 Apr 2020 01:07:09 +0200

On 25 Apr 2020, at 00:13, Brian Campbell <[email-masked]> wrote:

> The draft is trying to be agnostic to things like TLS being used from TRRP to Origin or not. But certainly doesn't rule it out. The intro has "...HTTPS is also usually employed between the proxy and the origin server…".

In essence, as a user of this I care only about two things:

- I care what was the cert; and
- I care who asserts this cert is legit.

The first bit is easy - the cert is in the header, I would like the second bit to be as easy as “verify a signature on the header”.

All the stuff about how it’s used is largely academic, as long as I get the above two things, I as a user am happy. What cert is used to sign? I don't want the RFC to care, that’s an implementation detail, let me choose a signature that works for me in my use case.

Key for me is the second line above - if I don’t have a cryptographically secure way to verify where the cert came from, the header is useless to me.

Regards,
Graham
—