> 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:ilari.liusva...@elisanet.fi] Sent: Sunday, August 2, 2015 11:29 AM To: David Benjamin <david...@chromium.org> Cc: Andrei Popov <andrei.po...@microsoft.com>; tls@ietf.org 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 > <ilari.liusva...@elisanet.fi> > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
