Re: [TLS] No cypher overlap
Florian Weimer wrote: > * Viktor Dukhovni: > >> In that case, it should be said that a client MUST NOT advertise >> TLS 1.3 unless it offers at least one of the TLS 1.3 MTI ciphers >> (or perhaps less restrictive at least one TLS 1.3 compatible cipher). > > Or the server should negotiate TLS 1.2 instead. > > Servers should already do something similar today: For an > extension-less TLS 1.2 handshake, they should negotiate TLS 1.1 > instead, to get a stronger PRF. The facts and reasoning in this short statement is flawed. The TLSv1.2 PRF uses SHA256 throughout, and the hash of the PRF in TLS is *NOT* negotiated through extensions, but through TLS cipher suites (which do not need extensions). TLSv1.2 has exactly one mandatory to implement ciphersuite: https://tools.ietf.org/html/rfc5246#section-9 TLS_RSA_WITH_AES_128_CBC_SHA and this cipher suite works perfectly fine without TLS extensions, and will be used with a SHA-1 PRF for TLSv1.0 & TLSv1.1 and with a SHA-256 PRF with TLSv1.2. The highest security level (in the NIST SP800-57 part1 sense) that you can get with this cipher suite is the equivalent of 128-bit -- but that requires that you use server certificates with RSA keys of at least 3072-bit. The most commonly used server certificates today use 2048-bit RSA keys and limit the security to 112-bit. The use of a SHA-1 PRF in TLSv1.0 and TLSv1.1 is perfectly OK with NIST SP800-57 part1 for 128-bit security. The "weakness" of extension-less TLSv1.2 affects only the the weakened digitally-signed transform and the behaviour suggested in rfc5246 section 7.4.1.4.1 for the absence of the signature_algorithms extension, and the incredibly behaviour that some implementations exhibit. In the history of TLS RFCs there are two examples of completely botched descriptions of default behaviour for a TLS extension when it is not sent. The first extreme is in the informational document rfc4492 (TLS cipher suites with Elliptic Curves), where it says, when the extension is absent, assume that the peer supports *EVERYTHING*. The opposite extreme nonsense is what TLSv1.2 describes for the TLSv1.2 signature extension when the extension is not sent, because it suggest a braindead self-limitation to an algorithm that had already been deprecated and end-of-lifed with only 2 years left when TLSv1.2 was published, and no such limitation exists in earlier TLS versions. -Martin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Commentary on the client authentication presentation slides
On Sat, Aug 1, 2015 at 4:48 AM Ilari Liusvaara wrote: > > On Tue, Jul 28, 2015 at 6:28 PM David Benjamin > wrote: > > > > > Are you intending that this mechanism be enabled by default for HTTP/2 > or > > > would the prohibition against renego still apply? Without any way for > the > > > client to tie the CertificateRequest to the HTTP request that > triggered it, > > > this mechanism would have many of the same problems as renego as far as > > > HTTP/2 is concerned. (I realize Microsoft has a draft floating around > for a > > > TLS_RENEG_PERMITTED HTTP/2 setting. The setting can control this too I > > > suppose.) > > Even if there would be way to tie it to request that triggered the request, > it would still IMO have some of the nastiest problems of renegotiation, > especially in context of HTTP/2 in web (the privilege involved is almost > impossible to handle in any sane way). > > > 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. 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. > 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.) 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. David ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Commentary on the client authentication presentation slides
On Sun, Aug 02, 2015 at 03:38:00PM +, David Benjamin wrote: > On Sat, Aug 1, 2015 at 4:48 AM Ilari Liusvaara > 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
