[TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto
The combination of DHE and TLS 1.3 session resumption via session tickets, can destroy the forward secrecy property that DHE was intended to provide. With the proposed removal of DHE-based 0-RTT from TLS 1.3, session resumption is the mechanism by which 0-RTT connections are established. When adopted into QUIC, this will then be a reduction in security as compared with the current QUIC Crypto protocol, which rapidly steps all connections up to having forward secrecy immediately after a 0-RTT connection. The 0-RTT connection is extremely desirable for use in QUIC, because of the impact on connection latency, a known critical issues in all HTTP(S) content acquisition. Currently, at least 75% of all QUIC connections use 0-RTT, and then enjoy forward secrecy for the bulk of their communications. I would like TLS 1.3 to provide similar forward-secrecy guarantees after a 0-RTT connection. If a symmetric-session-ticket-decryption-key was compromised by a server, as a result of a break-in, or a subpoena, then all traffic that depended on the session resumption tickets would be at risk. Moreover, a third party attacker that possessed such a key, or planned to acquire a copy, could "encourage" traffic to use session resumption by disrupting any connection. A common use case involves having a large number of servers that must all be equally able to resume a connection. As a result, encrypted session tickets, protected by a server's symmetric secret key, are generally the preferred mechanism for resumption. Thanks for you consideration, Jim Roskind ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto
On Fri, Apr 8, 2016 at 6:13 PM, Bill Cox wrote: > On Fri, Apr 8, 2016 at 1:50 PM, Jim Roskind wrote: > >> The combination of DHE and TLS 1.3 session resumption via session >> tickets, can destroy the forward secrecy property that DHE was intended to >> provide. With the proposed removal of DHE-based 0-RTT from TLS 1.3, >> session resumption is the mechanism by which 0-RTT connections are >> established. When adopted into QUIC, this will then be a reduction in >> security as compared with the current QUIC Crypto protocol, which rapidly >> steps all connections up to having forward secrecy immediately after a >> 0-RTT connection. >> > > I think I can accurately answer this: just use ephemeral keys during your > resumption handshake. Then only the first flight 0-RTT packets lack PFS, > just like with DHE 0-RTT. > Quite so. TLS 1.3 supports two PSK-resumption modes: 1. Pure PSK, which has somewhat better security properties than in TLS 1.2 2. PSK-ECDHE, which has similar security properties to those of QUIC, i.e., no-PFS for the first flight and PFS for subsequent flights I think it would be good to encourage people to use mode #2, but there are obvious reasons why performance-sensitive implementations might opt for mode #1. -Ekr > Just reiterating a point I think is important: the client needs to know > whether the server has replay protection in this case. It may decide to > use 1-RTT to have full PFS for all application data and real proofs of > possession for client certs, or it might decide to send 0-RTT data in any > case. However, we should advise clients not to send client certs and POST > requests over PSK 0-RTT resumes during the first flight, IMO. I'd like to > see tickets enhanced to enable the server to tell the client whether replay > protection is in place on the server. > > Bill > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto
On Fri, Apr 8, 2016 at 1:50 PM, Jim Roskind wrote: > If a symmetric-session-ticket-decryption-key was compromised by a server, > as a result of a break-in, or a subpoena, then all traffic that depended on > the session resumption tickets would be at risk. Moreover, a third party > attacker that possessed such a key, or planned to acquire a copy, could > "encourage" traffic to use session resumption by disrupting any connection. > Why isn't your concern just as valid for the 0RTT itself though? If it's a URL it's entirely possible for it to be privacy sensitive, or to have some kind of bearer token in it. Or the 0RTT might have POST-like data, like maybe your credit card number. -- Colm ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto
On Fri, Apr 8, 2016 at 6:42 PM, Wan-Teh Chang wrote: > On Fri, Apr 8, 2016 at 2:31 PM, Eric Rescorla wrote: > > > > ... TLS 1.3 supports two PSK-resumption modes: > > > > 1. Pure PSK, which has somewhat better security properties than in TLS > 1.2 > > 2. PSK-ECDHE, which has similar security properties to those of QUIC, > i.e., > > no-PFS for the first flight and PFS for subsequent flights > > > > I think it would be good to encourage people to use mode #2, but there > are > > obvious > > reasons why performance-sensitive implementations might opt for mode #1. > > I don't know why one wants to choose PSK-ECDHE resumption over ECDHE > full handshake. Does PSK-ECDHE resumption have any advantage over > ECDHE full handshake? Yes [0] 1. It has a significantly lower performance cost (especially if you have an RSA cert) 2. If you have done client authentication, then you can carry the state over between handshakes. 3. As it seems likely we are going to remove the (EC)DHE 0-RTT mode, this is how you do 0-RTT. -Ekr [0] For the sake of this discussion, I'm talking about resumption PSK when the server is authenticating with a cert. Obviously if you are using PSK-based authentication there are reasons why you would want to do this. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] [solwo...@rites.uic.edu: TLS weakness in Forward Secrecy compared to QUIC Crypto]
Looks like this didn't make it out to the list. Forwarding from my email address a message by Jon Solworth. - Forwarded message from "Jon A. Solworth" - Date: Fri, 8 Apr 2016 17:33:57 -0500 From: "Jon A. Solworth" To: tls@ietf.org, Tanja Lange , "D. J. Bernstein" , "W. Michael Petullo" Subject: TLS weakness in Forward Secrecy compared to QUIC Crypto It is not necessary to choose between either forward secrecy or low latency. It is possible to achieve both (and many other properties) as does MinimaLT. In MinimaLT, the current ephemeral key for the server is added to the DNS record fetched during the DNS lookup. These entries expire fairly quickly, ensuring that old keys are never used. The DNS lookup is necessary for other reasons, so there is no additional latency. This design avoids weak mechanisms and added complexity, two issues that cause enormous problems in security software. Jon Solworth - End forwarded message - ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [solwo...@rites.uic.edu: TLS weakness in Forward Secrecy compared to QUIC Crypto]
On Fri, Apr 8, 2016 at 10:26 PM, Tanja Lange wrote: > Looks like this didn't make it out to the list. Forwarding > from my email address a message by Jon Solworth. > > - Forwarded message from "Jon A. Solworth" > - > > Date: Fri, 8 Apr 2016 17:33:57 -0500 > From: "Jon A. Solworth" > To: tls@ietf.org, Tanja Lange , "D. J. Bernstein" > , "W. Michael Petullo" > Subject: TLS weakness in Forward Secrecy compared to QUIC Crypto > > It is not necessary to choose between either forward secrecy > or low latency. It is possible to achieve both (and many other > properties) as does MinimaLT. > > In MinimaLT, the current ephemeral key for the server > is added to the DNS record fetched during the DNS lookup. These entries > expire fairly quickly, ensuring that old keys are never > used. > > The DNS lookup is necessary for other reasons, so there > is no additional latency. > DNS-based priming is a seemingly attractive concept but unfortunately isn't really workable here, for several reasons: 1. It requires DNS security, which has relatively minimal deployment. We want 0-RTT to be available in TLS 1.3 even in environments without DNS security. 2. Measurements indicate that penetration rates for DNS records other than the basic ones that are necessary for nearly all operation (A, CNAME, etc.) are fairly poor, so this adds a number of operational problems. If you want to use short-lived ephemerals that are frequently refreshed in the DNS, thus providing forward secrecy you have the additional problem that most Web servers are not well integrated into the DNS server (one reason why Let's Encrypt initially launched with HTTP-based validation). With that said, if the deployment situation changes, it wouldn't be that hard to add a feature like this to TLS 1.3 in the future. Best, -Ekr > This design avoids weak mechanisms and added complexity, > two issues that cause enormous problems in security software. > > Jon Solworth > > - End forwarded message - > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
