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

[Ilari Liusvaara <[e-mail]>]

On Tue, Aug 04, 2015 at 12:37:47AM +0000, Andrei Popov wrote:
> > 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.

What sort of usecase you have in mind for this? I can't come up with
single one that I don't think is a hack at best.

Note: It is very easy to misuse capability like this (even if it is
restricted to work only once per connection) to create nasty security
issues (one example being trying to use this for HTTP/2 in browser
environment).

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

Where's the capability for client to unilaterially decide to send a
certificate without valid configuration? The 0-RTT certificate
authentication requires a valid configuration.

E.g. one way to implement that would be certificate_request_request
extension, which would request server to send a CertificateRequest.

Tho with the changes to always sign the key exchange, using 0-RTT
client certs doesn't work unless the server requested certificates
back then.

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

That was given as second of two entries in list of kinds of
authentication I think are useful (and precluding it would mean
removing TLS-Unique and TLS-Extractor, which is something that I really
don't see happening).




-Ilari