On Fri, Mar 25, 2016 at 8:33 AM, Bill Cox <waywardg...@google.com> 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? > > 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. > > 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. > PTAL at draft-12 which has a definition of exporters based on the Exporter Secret, which is computed at the end of the handshake. -Ekr > > > Bill > > _______________________________________________ > 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
