Re: Client-Cert Header draft

["Soni L." <[e-mail]>]

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 
> perspective anyway) and taking HTTP with the backend.
>
> On Fri, Apr 17, 2020 at 3:25 PM Soni L. <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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
>>>     <[e-mail] <mailto:[e-mail]>>
>>>     wrote:
>>>
>>>     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./