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

[Eric Rescorla <[e-mail]>]

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

> I didn't expect it to be any more persuasive. I was only hoping it'd be
> 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.


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."
>

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

-Ekr



>
> On Mon, Mar 30, 2020 at 12:13 PM Eric Rescorla <[e-mail]> wrote:
>
>>
>>
>> On Mon, Mar 30, 2020 at 10:38 AM Brian Campbell <
>> [e-mail]> wrote:
>>
>>>
>>> Thanks for the review and feedback, Eric. My attempts at
>>> answers/responses are inline below.
>>>
>>> On Fri, Mar 27, 2020 at 11:22 AM Eric Rescorla <[e-mail]> wrote:
>>>
>>>>
>>>> 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.
>>>>
>>>
>>> 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.
>>>
>>
>> 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
>>> 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.
>>>
>>
>> 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.
>>
>>
>>
>>>
>>>>
>>>> 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.
>>>>
>>>
>>> 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.
>>>
>>
>> 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.
>>
>>
>>
>>>
>>>
>>>> This also implies that you should have a way to pass extensions
>>>> 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?
>>>
>>
>> That's the situation now, but it might not be in the future.
>>
>>
>>>
>>>
>>>>
>>>> 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?
>>>>
>>>
>>> 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.
>>
>>
>>>
>>>>
>>>> 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?
>>>>
>>>
>>> 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
>>> 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.
>>>
>>>
>>>
>>>
>>>>
>>>> On Mon, Mar 2, 2020 at 1:51 PM Brian Campbell <bcampbell=
>>>> [e-mail]> 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).
>>>>>
>>>>> 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.*
>>>>> _______________________________________________
>>>>> Secdispatch mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/secdispatch
>>>>>
>>>>
>>> *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.*
>>
>>
> *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.*