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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
