Subject: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header

From: Brian Campbell <[email-masked]>
Date: Mon, 2 Mar 2020 14:50:30 -0700

Hello SecDispatchers and Chairs thereof,

I'd like to request some time on the agenda in Vancouver to present on
https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/
in an effort to gauge interest and potentially find an appropriate venue
for the work to proceed (or just put it and its ridiculously long title out
of its misery).

Client-Cert HTTP Header: Conveying Client Certificate Information from
     TLS Terminating Reverse Proxies to Origin Server Applications

Abstract

   This document defines the HTTP header field "Client-Cert" 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.

Discussion around the value of having something like this defined happened
in the OAuth WG a bit before the Singapore meeting (no doubt that's not the
only time but it's the one in which I was involved recently) and an AD
nudged me to secdispatch -
https://mailarchive.ietf.org/arch/msg/oauth/jQ5MAZ1XCvxWbHwqlT3ITEEQoKo/
falls somewhere in the middle of that long and sometimes contentious
thread. I was unable to get a draft published prior to the I-D submission
cut-off for Singapore and got a short "if time allows" presentation slot at
the meeting. The judgment coming out of that meeting was "needs draft".

I did get an actual draft published a bit after Singapore (the one with the
ridiculously long title previously mentioned) and there's been some, if not
exactly an overwhelming amount of, discussion and support of it on this
very list:
https://mailarchive.ietf.org/arch/search/?q=%22draft-bdc-something-something-certificate%22

Thanks.
Brian Campbell

-- 
_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: Michael Richardson <[email-masked]>
Date: Mon, 02 Mar 2020 18:54:16 -0500

> Abstract

I have previously read this document.
I was surprised it wasn't already a thing actually.

I can't see why it would any place other than HTTPbis.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Mar 2020 10:21:17 -0700

Overall, I agree that something like this is needed. However,
I have two concerns about the mechanism described here.

First, as you note in S B.1., if the header is not properly
sanitized, there is a trivial attack and there are stronger
mechanism that do not require sanitization:

   "Client-Cert" header that would appear to the backend to have come
   from the reverse proxy.  Although numerous other methods of
   detecting/preventing header injection are possible; such as the use
   of a unique secret value as part of the header name or value or the
   application of a signature, HMAC, or AEAD, there is no common general
   standardized mechanism.  The potential problem of client header
   injection is not at all unique to the functionality of this draft and
   it would therefor be inappropriate for this draft to define a one-off
   solution.  In the absence of a generic standardized solution existing
   currently, stripping/sanitizing the headers is the de facto means of
   protecting against header injection in practice today.  Sanitizing

This seems like an odd argument to make: if a strong mechanism is
in order, we should design one and make it generic, not just throw
and continue to use weaker mechanisms.

Second, I think it's quite unwise to only pass the EE cert. This
means that the server will be unable to independently evaluate
the cert chain, which (1) is unduly restrictive on the architecture
because it forces the proxy to do it and (2) means that there
is no backstop in the case where the proxy makes errors or
has a not-very-good validator. You should pass the whole chain.
This also implies that you should have a way to pass extensions
such as SCTs and stapled OCSP responses.

Finally, two points about TLS integration.

1. You should define how this works in the case of resumption
of a connection that had client auth. Should the proxy attach the
chain from the original connection?

2. How do you handle post-handshake client authentication? Specifically:
(a) How do you handle the situation in which part of the HTTP
request is covered by the client cert?

(b) Post-handshake client authentication allows for the client
to authenticate with multiple certificates one after the other.
How is this propagated to the server?

On Mon, Mar 2, 2020 at 1:51 PM Brian Campbell <bcampbell=
[email-masked]> wrote:

> I did get an actual draft published a bit after Singapore (the one with
> the ridiculously long title previously mentioned) and there's been some, if
> not exactly an overwhelming amount of, discussion and support of it on this
> very list:
> *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.*_______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 27 Mar 2020 12:37:04 -0700

> chain from the original connection?

Hmm, that requires the proxy to keep that state around (either locally or
in the resumption ticket).  Brainstorming, in TLS 1.3 one could also have
the application manage the authentication state by having the proxy not
issue tickets right at the handshake completion, and instead wait for the
application to return a blob to include in the ticket.  This would provide
a convenient excuse for adding a way to secure the proxy/backend channel,
with the proxy adding a header with a key fingerprint, and the backend
encrypting its response to that key, only if the key is whitelisted in the
application's configuration.  On the other hand, it's more moving parts,
it's TLS 1.3-only (since you can't wait to issue the ticket in 1.2), and
you'd have to have a way to distinguish whether the client cert (chain) or
the application's blob are being passed.  That might mean two or three
header fields going from proxy to backend, and more consistency
checking/error handling to match.

> request is covered by the client cert?

HTTP footers come to mind as the obvious channel from proxy to backend
that's available in HTTP and can be used for data that arrives "later".
But it induces perhaps even negative excitement to think of the prospect...

> How is this propagated to the server?

Also, do we care only about the list of what certificates were presented,
the order as well, and/or at what point in the bytestream each occurred?

-Ben

> _______________________________________________
> Secdispatch mailing list
> [email-masked]

---

From: Mohit Sethi M <[email-masked]>
Date: Fri, 27 Mar 2020 22:17:12 +0000

Hi Brian,

On further thought, I actually agree that passing the entire chain makes more sense. This would be useful if the TLS proxy doesn't have the trust anchor (but the backend server has it).

--Mohit

On 3/27/20 7:21 PM, Eric Rescorla wrote:

On Mon, Mar 2, 2020 at 1:51 PM Brian Campbell <bcampbell=[email-masked]<mailto:[email-masked]>> wrote:
Hello SecDispatchers and Chairs thereof,

I'd like to request some time on the agenda in Vancouver to present on https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/ in an effort to gauge interest and potentially find an appropriate venue for the work to proceed (or just put it and its ridiculously long title out of its misery).

Abstract

Discussion around the value of having something like this defined happened in the OAuth WG a bit before the Singapore meeting (no doubt that's not the only time but it's the one in which I was involved recently) and an AD nudged me to secdispatch - https://mailarchive.ietf.org/arch/msg/oauth/jQ5MAZ1XCvxWbHwqlT3ITEEQoKo/ falls somewhere in the middle of that long and sometimes contentious thread. I was unable to get a draft published prior to the I-D submission cut-off for Singapore and got a short "if time allows" presentation slot at the meeting. The judgment coming out of that meeting was "needs draft".

I did get an actual draft published a bit after Singapore (the one with the ridiculously long title previously mentioned) and there's been some, if not exactly an overwhelming amount of, discussion and support of it on this very list: https://mailarchive.ietf.org/arch/search/?q=%22draft-bdc-something-something-certificate%22

Thanks.
Brian Campbell

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._______________________________________________
Secdispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/secdispatch

_______________________________________________
Secdispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Michael Richardson <[email-masked]>
Date: Sun, 29 Mar 2020 18:13:39 -0400

>> and continue to use weaker mechanisms.

I agree: it seems like we ought to make some kind of more generic mechanism.
It feels like we are creating a new reverse-proxy/framework channel.
The stupidest version I can imagine is two sets of HTTP headers... message/rfc822 like.

There are a bunch of such interfaces around already, and maybe we can do this
if we assume HTTP/2 here.

Benjamin Kaduk <[email-masked]> wrote:
    > application's configuration.  On the other hand, it's more moving

I think that you two have potentially given a reasonable technical reason why
this work is not as trivial as envisioned, and that we need to boil a bit
more water here, without an entire ocean.  That maybe it requires a
significant part of a WG, if not an entire WG.

It was mentioned that HTTPBIS plans to cleave of some pieces, but I don't
have the time to follow all of HTTPBIS...

---

From: Brian Campbell <[email-masked]>
Date: Mon, 30 Mar 2020 11:37:35 -0600

Thanks for the review and feedback, Eric. My attempts at answers/responses
are inline below.

> and continue to use weaker mechanisms.

Ironically, that text was written (at least in part) in an attempt to head
off having this very argument with you. We (you and I specifically) have
been down this road before discussing essentially the same issue with
respect to (the now defunct for unrelated reasons)
https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ and there sure
didn't seem to be be sufficient appetite to work on a generic solution.
Maybe that's changed and there is more of an appetite now? Maybe. There was
some talk at the secdispatch session of the prospect of spinning up or
splitting off a WG to work on reverse proxy stuff. But a lot more than talk
is needed and I maintain that, in the absence of something generic being
defined and widely available, the de facto is sufficiently good and
appropriate for a document/draft like this.

> has a not-very-good validator. You should pass the whole chain.

Passing the end-entity cert vs. including intermediates or the whole chain
is something that's up for discussion should this document find a home
where it can be worked on and progressed. As with most things, there are
tradeoffs involved.

What you describe as unduly restrictive, however, could also be viewed as
properly constraining different components to doing the most appropriate
functionality. The backend server doing the validation would mean it has to
evaluate the cert chain on every request (which is likely prohibitively
expensive with multiple public key opperations) and/or have some
complicated caching. And allowing either piece to do the validation could
also increase the likelihood that things are set up such that neither
actually does it.

> such as SCTs and stapled OCSP responses.

I was under the (maybe naive) impression that such things were largely or
even exclusively for the server side and not applicable or defined for the
client side?

Regardless, I'd view this as additional reasons for why it's more
appropriately restrictive for the reverse proxy to be checking the
certificate validity and only passing the cert back to the backend on
successful validation.

> chain from the original connection?

Is such a resumed connection still considered to be client authenticated? I
thought so and thus my assumption/expectation was that yes the proxy would
attach the chain from the original connection. Is that problematic for some
reason? Or are you just saying that it needs to be stated explicitly in the
document?

> How is this propagated to the server?

I'd been thinking that post-handshake authentication and renegotiation were
forbidden so these questions were out of scope. But I guess that only
applies to HTTP/2?

So, off-the-cuff I'd say that for (a) the header is only passed on requests
that are covered in full by the cert. But that pragmatically it's super
difficult or impossible with the APIs in the average environment to figure
out what application data came before or after the cert auth and so it'll
end up being however a particular proxy implementation treats this
situation currently but just with a standard header. For (b) I'd say only
propagate the most recent one.

Having given my half-assed answers though, I'd welcome input if you think
there are better answers.

>> Discussion around the value of having something like this defined
>> happened in the OAuth WG a bit before the Singapore meeting (no doubt
>> that's not the only time but it's the one in which I was involved recently)
>> and an AD nudged me to secdispatch -

---

From: Brian Campbell <[email-masked]>
Date: Mon, 30 Mar 2020 12:03:24 -0600

As I just tried to articulate to EKR in the last mail, passing the
end-entity cert vs. including intermediates or the whole chain, or
something else is a topic that's up for discussion should this document
find a home where it can be worked on and progressed. But as it true with
most things, there are tradeoffs involved. And as explained in the draft,
my first best attempt at finding the right place in the tradeoffs was to go
with the end-entity cert and not more or less.

On Fri, Mar 27, 2020 at 4:17 PM Mohit Sethi M <mohit.m.sethi=
[email-masked]> wrote:

> Hi Brian,
>
> On further thought, I actually agree that passing the entire chain makes
> more sense. This would be useful if the TLS proxy doesn't have the trust
> anchor (but the backend server has it).
>
> --Mohit
> Secdispatch mailing [email-masked]://www.ietf.org/mailman/listinfo/secdispatch
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Mar 2020 11:12:23 -0700

> didn't seem to be be sufficient appetite to work on a generic solution.

Well, I don't know why you think that I would have found it more persuasive
this time around.

> appropriate for a document/draft like this.

Well, if what you want is a code point registration for something that's de
facto, then sure, but if you want to have an IETF PS, then the solution
should reflect what we ordinarily consider to be best practice.

> also increase the likelihood that things are set up such that neither

ISTM that we have quite a bit of experience with MITM proxies (a slightly
different setting) and the quality of checking varies wildly, so I would
prefer to leave the origin server with the ability to do this work.

> even exclusively for the server side and not applicable or defined for the

That's the situation now, but it might not be in the future.

> Is such a resumed connection still considered to be client authenticated?
> I thought so and thus my assumption/expectation was that yes the proxy
> would attach the chain from the original connection. Is that problematic
> for some reason? Or are you just saying that it needs to be stated
> explicitly in the document?
>

I'm saying that it needs to be in the document.

> I'd been thinking that post-handshake authentication and renegotiation
> were forbidden so these questions were out of scope. But I guess that only
> applies to HTTP/2?
>

I'm not aware of any restriction on post-handshake auth for H2 (H2 was
designed before TLS 1.3).

-Ekr

> So, off-the-cuff I'd say that for (a) the header is only passed on
> requests that are covered in full by the cert. But that pragmatically it's
> super difficult or impossible with the APIs in the average environment to
> figure out what application data came before or after the cert auth and so
> it'll end up being however a particular proxy implementation treats this
>>> your computer. Thank you.*
> review, use, distribution or disclosure by others is strictly prohibited.
> your computer. Thank you.*

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 30 Mar 2020 18:16:11 +0000

I support this document. A standardized place for a TLS-terminating intermediary to present the certificate to an origin is a good thing.  It will make CDN customers more portable.

Maybe this is a point solution that most of the Internet doesn’t care about.  But measurable portion should care and would benefit.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Mar 2020 11:21:13 -0700

I'm not arguing that we shouldn't do this work; I'm saying that if we are
to publish it as a PS, then we should not do something we know to be very
brittle.

-Ekr

On Mon, Mar 30, 2020 at 11:17 AM Salz, Rich <[email-masked]> wrote:

> I support this document. A standardized place for a TLS-terminating
> intermediary to present the certificate to an origin is a good thing.  It
> will make CDN customers more portable.
>
>
>
> Maybe this is a point solution that most of the Internet doesn’t care
> about.  But measurable portion should care and would benefit.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 30 Mar 2020 18:25:36 +0000

*   I'm not arguing that we shouldn't do this work; I'm saying that if we are to publish it as a PS, then we should not do something we know to be very brittle.

I am not sure it’s brittle.  But that is something for the WG to discuss.  The intermediary is already asserting all sort of things about the client :)

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Mar 2020 15:42:48 -0400

Salz, Rich <rsalz=[email-masked]> wrote:
    > intermediary to present the certificate to an origin is a good thing.
    > It will make CDN customers more portable.

    > about.  But measurable portion should care and would benefit.

Do you want a new WG, HTTPBIS, the proposed HTTPSBIS-offshoot, TLS, or ???

I concur with how important it is.
Is there an email chain about the HTTPSBIS offshoot, btw?

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Mar 2020 12:48:36 -0700

I do not believe this should be in TLS, as it is not a change to the TLS
protocol. I do, however, believe that the TLS WG should be consulted
because of the types of technical issues I raised in my review.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 30 Mar 2020 19:51:50 +0000

It belong with HTTP, I don't care where.

---

From: Brian Campbell <[email-masked]>
Date: Mon, 30 Mar 2020 14:36:44 -0600

The outcome from SECDISPATCH last week, as I understand it, is that the
next step is to take the work to the HTTPbis WG and see if there's there's
sufficient interest there in taking it up. I plan to get that started soon
(for some value of soon anyway).

There was some discussion on mic and in jabber about spinning up or out a
new WG with a focus on proxy to backend type stuff. But I don't think it
rose to the level of being something actionable coming out of the meeting.

---

From: Brian Campbell <[email-masked]>
Date: Mon, 30 Mar 2020 15:02:58 -0600

I didn't expect it to be any more persuasive. I was only hoping it'd be
sufficient to avoid relitigating the whole thing. Especially because, short
of spinning up a significant bit of new work, I don't see how the outcome
will be any different. I'm not looking for just for a code point
registration for something that's de facto. I'm endeavoring to bring some
level of commonality to a situation that happens in practice now so as to
hopefully improve interoperability.

Indeed the situation may not be quite as straightforward as I have
presented it in an early revision of an individual draft. But I'd suggest
that characterizing it as "very brittle" is a bit hyperbolic.

In working on the document I did try to educate myself somewhat on things
that would be less than straightforward. When doing that I came across the
recently published RFC 8740, which "updates RFC 7540 [HTTP/2] by forbidding
TLS 1.3 post-handshake authentication."

On Mon, Mar 30, 2020 at 12:13 PM Eric Rescorla <[email-masked]> wrote:

>
>
> On Mon, Mar 30, 2020 at 10:38 AM Brian Campbell <
> [email-masked]> wrote:
>
>>
>> Thanks for the review and feedback, Eric. My attempts at
>> answers/responses are inline below.
>>
>> Ironically, that text was written (at least in part) in an attempt to
>> head off having this very argument with you. We (you and I specifically)
>> have been down this road before discussing essentially the same issue with
> Well, I don't know why you think that I would have found it more
> persuasive this time around.
>
>
> Maybe that's changed and there is more of an appetite now? Maybe. There
>> was some talk at the secdispatch session of the prospect of spinning up or
> Well, if what you want is a code point registration for something that's
> de facto, then sure, but if you want to have an IETF PS, then the solution
>> Passing the end-entity cert vs. including intermediates or the whole
>> chain is something that's up for discussion should this document find a
>> home where it can be worked on and progressed. As with most things, there
>> are tradeoffs involved.
>>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Mar 2020 17:57:09 -0700

On Mon, Mar 30, 2020 at 2:03 PM Brian Campbell <[email-masked]>
wrote:

> sufficient to avoid relitigating the whole thing.
>

For obvious reasons, I'm not that excited about that.

Especially because, short of spinning up a significant bit of new work, I
> don't see how the outcome will be any different. I'm not looking for just
> for a code point registration for something that's de facto. I'm
> endeavoring to bring some level of commonality to a situation that happens
> in practice now so as to hopefully improve interoperability.
>

Again, I'm fine to see an informational document with a code point
registration, but the import of a Proposed Standard is that the IETF thinks
this is a good idea, and ISTM that the design you have proposed is not in
fact have security properties we would otherwise want.

> TLS 1.3 post-handshake authentication."

Ah, good. So this just applies to HTTP 1.1.

-Ekr

>>> https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ and there
>>> sure didn't seem to be be sufficient appetite to work on a generic
>>> solution.
>>>
>>
>>> What you describe as unduly restrictive, however, could also be viewed
>>> as properly constraining different components to doing the most appropriate
>>> I was under the (maybe naive) impression that such things were largely
>>> or even exclusively for the server side and not applicable or defined for
>>> the client side?
>>>
>>
>>> Is such a resumed connection still considered to be client
>>> authenticated? I thought so and thus my assumption/expectation was that yes
>>> the proxy would attach the chain from the original connection. Is that
>>> problematic for some reason? Or are you just saying that it needs to be
>>> stated explicitly in the document?
>>>
>>
>>> Having given my half-assed answers though, I'd welcome input if you
>>> think there are better answers.
>>>
>>>
>>>
>>>
>>>>
>>>>> I did get an actual draft published a bit after Singapore (the one
>>>>> with the ridiculously long title previously mentioned) and there's been
>>>>> some, if not exactly an overwhelming amount of, discussion and support of
>>>>> it on this very list: