On Wed, Mar 16, 2016 at 12:33:40AM -0400, Colm MacCárthaigh wrote: > On Tue, Mar 15, 2016 at 9:38 PM, Bill Cox <waywardg...@google.com> wrote: > > > I would be happy if we could recommend at least one reasonably secure > > method for 0-RTT for HTTPS that has a reasonable chance of satisfying the > > skeptics, and then state that 0-RTT for other protocols, and stateless > > 0-RTT, needs to be carefully considered for the application. > > > > After meditating on this a little, how about something like this: > > Benefits Forward secrecy: > > * Clients SHOULD use a resumption ticket only once, and get a new > resumption ticket when using an existing one. > > Benefits Forward Secrecy and Idempotence: > > * Client and server should erase the existing ticket upon use. > > (a captured early data section is mooted for replay quite quickly in the > default "good" case)
The best that can be done w.r.t. "forward secrecy" is to erase the decryption-capable key used for 0-RTT on both sides, and never sending it on the wire, even encrypted. > * Make early data and application data separate record layer content types. > Make it clear that they do not form a continuous stream; you can't simply > concatenate them at the application level and bolt on to existing protocols > such as HTTP, SMTP, etc. You mean inner (encrypted) content type, right (outer content type would still be 23[TLS PROTECTED DATA]? > * Advise that clients using 0RTT SHOULD occasionally send duplicate early > data handshakes. As a normal part of the protocol, a well behaved client > should intentionally do what an attacker might do and send the whole > section twice, causing the server to resolve the duplication. Keep the > anti-bodies strong. Such duplication does not occur in attack conditions. The duplication from attack conditions takes two forms: - Duplication of 0-RTT data into 1-RTT data of _different_ connection. - Duplication of 0-RTT data into 0-RTT data of _different_ connection. In both cases, the connections are different, not the same. And this makes a difference if e.g. protocol banners are sent as 0-RTT (and such may very well be critical for latency). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
