Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context)

[Ilari Liusvaara <[e-mail]>]

On Fri, Mar 25, 2016 at 08:33:20AM -0700, Bill Cox wrote:
> Adding 1 byte EarlyDataType seems like a good idea.
> 
> As for the CipherSuite, assuming DH-0RTT goes away, would it be simpler to
> require that the cipher suite negotiated from the original 1-RTT connection
> be used?

TLS_PSK_* or TLS_ECDHE_PSK_*? Apparently the design currently includes
doing ECDHE_PSK_* together with PSK for 0-RTT. And the unified session
resumption is pure-PSK.

So it would look like there are at least two valid ciphersuites...
 
> For channel binding, the only mode that seems to work with 0-RTT is when we
> issue new tickets on each 0-RTT connection to emulate a single session like
> we have in TLS 1.2, and use a replay cache on the server.  The only valid
> proof-of-possession the server can do with the client before processing
> application requests is the one done on the 1-RTT connection, so this
> single proof needs to secure the entire chain of 0-RTT connections.  The
> master resumption secret becomes a bearer token and needs to be protected
> accordingly.

Once the crypto problems with DH-0RTT are fixed, one can use that with
similar guarantees, but without sensitive state being kept by the client.
 
> The Export Key Material API also needs to be updated.  The simplest
> implementation where keys are derived from the current ephemeral secrets
> will cause the exported keys to be different whenever new keys are
> negotiated.  This will probably cause bugs at the application layer.  We
> may need to have an EKM API that depends only on the original PSK, and
> another one for generating ephemeral EKM material.

Err... You mean new exporter keys when doing new handshake? If so, that
is intended. Or new exporter keys when rolling over keys? IIRC, key
rollover only updates traffic keys, not the key used for exporter.

And also, at TLS level? What is the "original PSK"?


-Ilari