Re: [TLS] Commentary on the client authentication presentation slides

[Andrei Popov <[e-mail]>]

> Well, TLS is also used for non-browser HTTPS and stuff other than HTTPS.
> There one likely "preconfigures" client certificates if needed.
The proposed client authentication mechanism specifically addresses the case where the client does not have one "preconfigured" cert.

> - TLS-level client certificate auth on client request on connect (this
>  currently can't be cleanly done, sometimes one even sees that "renego
>  immediately to provoke CR" hack).
With the proposed change, there will be no need to renegotiate in order to authenticate the client.

 > - Application-level client auth (via CB capability of TLS).
The proposed mechanism does not preclude this option.

Cheers,

Andrei

-----Original Message-----
From: Ilari Liusvaara [mailto:[e-mail]] 
Sent: Sunday, August 2, 2015 11:29 AM
To: David Benjamin <[e-mail]>
Cc: Andrei Popov <[e-mail]>; [e-mail]
Subject: Re: [TLS] Commentary on the client authentication presentation slides

On Sun, Aug 02, 2015 at 03:38:00PM +0000, David Benjamin wrote:
> On Sat, Aug 1, 2015 at 4:48 AM Ilari Liusvaara 
> <[e-mail]>
> wrote:
> >
> > What I think would be very useful: A way for client to signal it has 
> > a client certificate it expects to use, regardless of if valid 
> > configuration is known. The vast majority of times client 
> > certificate is used, the client knows about that before initiating a connection.
> 
> Unless I misunderstand you, this isn't true for a browser. Browsers 
> only look for client certificates based on a CertificateRequest 
> message. Some platforms, like Android, don't even let you list the 
> user's certificate store. Instead there's an API to show a trusted certificate picker prompt.

Well, TLS is also used for non-browser HTTPS and stuff other than HTTPS.
There one likely "preconfigures" client certificates if needed.

> Or, given the paragraph below, are you suggesting that we'd start a 
> second connection on receiving CertificateRequest and only advertise it then?
> Yeah, that's actually how Chrome implements client auth anyway. We 
> always start a second connection with a client certificate configured, 
> even if the server sent CertificateRequest on a renego. It makes a few things simpler.

Doesn't that count as "knowing about client certificate before connecting"
(even if the knowledge has been received split-second before TLS handshake starts)?

Also, signaling can be at application layer, as talked about below.

> > IMO, the proper way to handle "this resource requires client certificate"
> > is for server to signal that in application protocol and then client 
> > to establish a new connection with client certificate (or if 
> > application protocol supports it, do the authentication at 
> > application layer without ever involving TLS, except for channel binding).
> 
> Certainly. Chrome doesn't implement TLS_RENEG_PERMITTED for HTTP/2, 
> and I don't want to allow this mechanism for it either. I consider 
> renego-based per-resource client auth in HTTP/1.1 to be a legacy 
> mistake we're currently stuck with. (It's the only reason we ever have 
> to renego. In BoringSSL, we've settled on stripping renego down to the 
> bare minimum needed to support this. Simplifies a lot of stuff.)

Yeah, I consider it (renego auth in HTTP/1.1) a poor idea as well, and I consider it would be actively dangerous in browser HTTP/2 (due to the multipoint nature of the environment and multiplexed nature of HTTP/2)...
Good thing it is banned.

> I'm guessing Microsoft has different constraints/goals, given this 
> proposal and TLS_RENEG_PERMITTED, so if we must have it in the 
> transport, I'd rather it be some opt-in corner that I don't have to 
> deal with. (Applications can return HTTP_1_1_REQUIRED in HTTP/2 if 
> they really must do per-resource client auth.) But I do agree this is 
> a problematic mechanism and don't think it belongs in TLS. Let the 
> application layer do it with a channel binding. No need for new 
> connections, and no messy questions about scope and multi-request protocols.

Summary of what auth modes I think are needed:

- TLS-level client certificate auth on client request on connect (this
  currently can't be cleanly done, sometimes one even sees that "renego
  immediately to provoke CR" hack).
- Application-level client auth (via CB capability of TLS).



-Ilari