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

[Brian Campbell <[e-mail]>]

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 <[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._