Subject: [Unbearable] Support for TLS 1.3

From: Bill Cox <[email-masked]>
Date: Thu, 7 Apr 2016 09:12:53 -0700

TLS 1.3 has these modes of operation of interest, assuming the ECDH 0-RTT
mode is dropped:

1) Normal 1-RTT handshakes on every connection
2) 1-RTT hashshake on initial connection, and 1-RTT PSK resumes thereafter
3) 1-RTT handshake on initial connection, and 0-RTT PSK resumes thereafter,
where the server provides protection against replay, such as emulating a
session cache
4) 1-RTT handshake on initial connection, and 0-RTT PSK resumes w/
stateless servers that allow 0-RTT application request replay

Mode 1 is easy.  The current TB spec applies directly.

Mode 2 is similar to TLS 1.2 resume, where we sign on every resume.  I
think we should do the TB signature on every resume, just like TLS 1.2.
However, we may get some push-back because the only point of 1-RTT PSK
resume in most cases will be to avoid extra public key operations.

Mode 3 is almost identical in security to mode 2.  I think we should also
do the TB signature in this mode.  By signing the client handshake hash, we
ensure that the TB signature is unique, and was made since the RMS was
derived.  If the TB private key is secured in some hardware thingy, then
resumption will not be possible without access to the thingy.

Mode 4 is where the server already risks replay attacks and loses some
forward secrecy in order to improve scalability by running the servers in a
stateless mode.  The RMS will be encoded in the ticket, and the same ticket
can be used for PSK 0-RTT resume many times.  In this mode, there is little
additional security to be had by signing the client handshake hash, since
the server cannot be sure that the signature is unique, and the proof of
possession fails, opening up all kinds of new attacks.  Currently, TLS 1.3
does not allow the client to know whether the server has replay protection
or not, so the safe thing would probably be to always do the TB signature,
even though the additional latency overhead does not seem justified by the
additional security benefit when doing stateless PSK 0-RTT resumption.

Bill

---

From: Andrei Popov <[email-masked]>
Date: Thu, 7 Apr 2016 20:55:09 +0000

This makes sense to me, but I think in case #4 TB does not help, and therefore should not be done (except when the TLS master secret is also HW-protected, just like the TB private key).

Another problem is that the client has no way to distinguish #3 and #4. So the only secure thing a client can do is to either not use TB in 0-RTT or to make the TLS master secret non-exportable.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Bill Cox
Sent: Thursday, April 7, 2016 1:13 PM
To: Tokbind WG <[email-masked]>
Subject: [Unbearable] Support for TLS 1.3

TLS 1.3 has these modes of operation of interest, assuming the ECDH 0-RTT mode is dropped:

1) Normal 1-RTT handshakes on every connection
2) 1-RTT hashshake on initial connection, and 1-RTT PSK resumes thereafter
3) 1-RTT handshake on initial connection, and 0-RTT PSK resumes thereafter, where the server provides protection against replay, such as emulating a session cache
4) 1-RTT handshake on initial connection, and 0-RTT PSK resumes w/ stateless servers that allow 0-RTT application request replay

Mode 2 is similar to TLS 1.2 resume, where we sign on every resume.  I think we should do the TB signature on every resume, just like TLS 1.2.  However, we may get some push-back because the only point of 1-RTT PSK resume in most cases will be to avoid extra public key operations.

Mode 3 is almost identical in security to mode 2.  I think we should also do the TB signature in this mode.  By signing the client handshake hash, we ensure that the TB signature is unique, and was made since the RMS was derived.  If the TB private key is secured in some hardware thingy, then resumption will not be possible without access to the thingy.

Mode 4 is where the server already risks replay attacks and loses some forward secrecy in order to improve scalability by running the servers in a stateless mode.  The RMS will be encoded in the ticket, and the same ticket can be used for PSK 0-RTT resume many times.  In this mode, there is little additional security to be had by signing the client handshake hash, since the server cannot be sure that the signature is unique, and the proof of possession fails, opening up all kinds of new attacks.  Currently, TLS 1.3 does not allow the client to know whether the server has replay protection or not, so the safe thing would probably be to always do the TB signature, even though the additional latency overhead does not seem justified by the additional security benefit when doing stateless PSK 0-RTT resumption.

Bill