Recent attacks like SLOTH, DROWN, PCKS1.5 padding oracles have shown that attacks on previous version of TLS can be used to attack new version of TLS.
One thing that is not mandated by TLS 1.3 is separation of session tickets and session ids between TLS protocols. For example a client could use a ticket negotiated with a previous version of TLS with TLS1.3. This could result in interesting situations: 1. Bypassing client auth If a server restricts a super-secure resource only over TLS1.3 with client auth and also shares ticket keys across TLS1.2 and TLS1.3. If an attacker has a SLOTH client impersonation attack against TLS1.2, they can get a TLS ticket from TLS1.2 connection issued by a server. The ticket would have the original client auth encrypted in it. The attacker could then use the ticket with TLS1.3 PSK resumption and authenticate as the original client. 2. PSK 0-RTT If the client agrees to use the ticket negotiated over a previous TLS1.2 connection in a subsequent handshake as the PSK for 0-RTT TLS1.3. An attacker that has a SLOTH attack for server impersonation could inject their own TLS ticket into the connection with a client in a TLS1.2 handshake. The 0-RTT data would be encrypted with an attacker known key and they could decrypt the 0-RTT data. If the connection continues to use PSK, the attacker can decrypt more data, however if the connection uses PSK + (EC)DHE then the attackers capability will be limited to decrypting the 0-RTT data. 3. Using DROWN style attacks The ticket from a TLS1.3 handshake can be used in the context of a TLS1.0 - TLS1.2 handshake. This might cause interesting new attacks to open up where a TLS1.3 ticket is forwarded to a TLS1.0 - TLS1.2 server. Even if a server enforces strict key separation between different TLS versions (which is very difficult), if tickets or session ids are reusable across TLS versions either on the client or the server, I believe these types of attacks remain possible. We could consider adding a section detailing the requirements for tickets for security. Even though there is a recommended construction, we could require a few things for the security of TLS 1.3: 1. Adding original TLS version to the ticket, so that TLS1.3 server can reject tickets issued by previous versions to prevent client authentication forgeries 2. Restricting 0-RTT data to only be encrypted with PSKs issued during a previous TLS 1.3 handshake, so that 0-RTT and other data cannot be decrypted 3. If a PSK is set via a ticket or session id, PSK modes for both normal PSK as well as 0-RTT should be only used with the protocol it was first negotiated with and prevent fallback. For example if a client received a PSK from TLS1.3, it should not allow either 0-RTT or resumed handshakes using that ticket to fallback back to lower protocols. Before a client knows that a server supports TLS1.3 and if a client allows TLS1.2 fallbacks, I don't think there's anything we can do to prevent that downgrade to TLS1.2 (apart from naming TLS 1.3 resources differently), however once TLS1.3 is negotiated, the above things will prevent downgrade to TLS1.2. Cheers, Subodh Iyengar
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
