Re: Client-Cert Header draft

[Brian Campbell <[e-mail]>]

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.





On Fri, Apr 17, 2020 at 4:31 PM Eric Rescorla <[e-mail]> wrote:

>
>
> On Fri, Apr 17, 2020 at 12:23 PM Mike Bishop <[e-mail]> 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.
>>
>
> I'm sure unsurprisingly to nobody, I second Mike's comments here.
>
> -Ekr
>
>
>>
>> But all that is refinement – the core concept here is beneficial, and I’d
>> like to see more engagement here.
>>
>>
>>
>> *From:* Brian Campbell <[e-mail]>
>> *Sent:* Wednesday, April 15, 2020 5:01 PM
>> *To:* HTTP Working Group <[e-mail]>
>> *Subject:* Client-Cert Header draft
>>
>>
>>
>> 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.*
>>
>

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