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
