Re: Client-Cert Header draft

[David Benjamin <[e-mail]>]

HTTP 403 and especially application level controls do not work. While some
misconfigured servers do report the error outside TLS, they are
misconfiguration. As a client, we consider this scenario unsupported. The
poor caching behavior is on the server operator, as the defined mechanism
for reporting a TLS client certificate error, namely a TLS alert, was not
used.

We should not standardize a misconfiguration. Wanting to separate TLS
termination from access control is plausible, but any attempt to solve this
problem must be done holistically. This includes defining error-handling
and making sure it actually works.

On Mon, Apr 20, 2020 at 6:14 PM Brian Campbell <[e-mail]>
wrote:

> Very true that connection-level authentication doesn't always play well
> with HTTP. But the intended scope of this draft isn't trying to address
> that. It's only trying to bring some commonality to what's typically done
> in practice now. I would think an HTTP 403 or even application level
> controls on content is what's happening now regardless. The approach in
> this draft does mean that authorization errors aren't going to be conveyed
> back to the client at the connection level but, as you point out, doing so
> is differently odd. So much so that I don't think the draft needs to do
> anything to facilitate it.
>
> On Fri, Apr 17, 2020 at 3:12 PM David Benjamin <[e-mail]>
> wrote:
>
>> This draft isn't sufficient to properly move the access checks out of the
>> TLS terminator. More care is needed here. There is a "distaste for client
>> certificates from some quarters" for a reason.
>>
>> In general, connection-level authentication does not play well with HTTP.
>> Server identities are generally public, so there is no complex policy
>> around when to release them. Client identities are generally user
>> identities and thus sensitive, with local policies, usually involving user
>> prompts and selections. That interacts badly with client certificates. It
>> just barely works today, but moving individual components without thought
>> as to the overall picture will break it.
>>
>> In particular, client HTTP stacks necessarily cache client certificate
>> decisions. Without caching, the user is potentially prompted on every HTTP
>> request, but a user session involves many HTTP requests. Additionally, the
>> decision is inherently cached by way of connection reuse and session
>> resumption optimizations. Short of forcing a full TLS handshake on every
>> HTTP request, clients could not prompt on every HTTP request if they wanted
>> to. That means the HTTP stacks need an explicit signal, or no amount of
>> reloads will allow the user to select a different identity.
>>
>> Currently, the only signal for a bad client certificate is a fatal TLS
>> alert. If the access checks are moved, bad client certificate signals will
>> come out of the origin server, which cannot generate those. This draft may
>> need to define a suitable HTTP 4xx code to correspond with TLS client
>> certificate authentication. Of course, existing clients won't know to
>> process that, but perhaps the origin server should translate to a TLS
>> alert? But then the response is never delivered, which may be differently
>> odd. Then one must consider the interaction with HTTP/2, which multiplexes
>> streams and potentially multiple origins together.
>>
>> There may be further problems here that I haven't thought through. The
>> suggestion of this enabling finer-grained access control worries me.
>>
>> On Fri, Apr 17, 2020 at 3:29 PM Lucas Pardue <[e-mail]>
>> wrote:
>>
>>> +1 to everything Mike said
>>>
>>> On Fri, 17 Apr 2020, 20:24 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.
>>>>
>>>>
>>>>
>>>> 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.*