On Tue, Mar 29, 2016 at 12:57 PM Subodh Iyengar <sub...@fb.com> wrote:
> 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: > I agree that the spec should clearly forbid cross-version resumption. I filed https://github.com/tlswg/tls13-spec/issues/136 some time ago about this. It got closed since session resumption was reworked for 1.3, but it doesn't look like the clarifications on matching versions ever happened, just the removal of the bad client advice. On the server, OpenSSL already includes the version in the SSL_SESSION structure, and recent enough versions of it will not accept sessions at the wrong version: https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=9e189b9dc10786c755919e6792e923c584c918a1 No client implementation which I tested allowed a server to do this either. They treated it as a fatal connection error. (Which also means there is no reason for a server to do it because it will not work anyway.) > 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. > I disagree with point #3 and think the "prevent fallback" portion would be a mistake. Possession of a TLS 1.3 session to offer should not disable TLS 1.2 if the client would have accepted this without that session. It's the same as my complaint about RFC 5246 E.1's paragraph in the bug linked earlier. While it is enticing to do away with TLS 1.2 this way, the reality is deployments are messy and can be heterogeneous. The service may be in the middle of deploying (or rolling back!) a change across many machines. Or perhaps it's not as well-managed and simply has two completely different machines behind it. We've seen problems in Chrome due to version-locking behavior in OpenSSL against real services with, say, one TLS 1.0 machine and one TLS 1.2 machine. They did not cross-resume sessions, but it doesn't matter. By the time you find that out, the version has been locked. (This prompted a rewrite in BoringSSL. The problem has also recently been fixed on OpenSSL master.) TLS client session caches are caches. Entries may be dropped from them at any point. It would be a mistake to use this kind of volatile state for downgrade protection. Further, some implementations will drop sessions on fatal alerts ("Upon transmission or receipt of a fatal alert message, both parties immediately close the connection. Servers and clients MUST forget any session-identifiers, keys, and secrets associated with a failed connection. Thus, any connection terminated with a fatal alert MUST NOT be resumed."), so this could easily be bypassed. Instead, TLS 1.3 adds this mechanism which I think is much preferable: https://github.com/tlswg/tls13-spec/pull/284 David > Cheers, > Subodh Iyengar > _______________________________________________ > 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
