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) Benefits Idempotence; * 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. * 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. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
