On Wed, Mar 16, 2016 at 4:17 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> > 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. > That's why I favor resuming connections where they left off, and cranking a PRF to generate new keys; but it's not compatible with tickets at all - works only with some kind of session store. > > * 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]? > Yep, sorry. > > * 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. > I think using a different content type solves this; the early data is illegal in the 1-RTT phase and the content type would distinguish it. > - 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). > The client would do what an attacker would; occasionally duplicate the handshake including early data, so it would use a different connection for it. The purpose here is to force a kind of "continuous testing in production" that means the protocol really really does have to have idempodence solved. As an aside: an application protocol where latency is so sensitive that 0RTT is attractive would hardly have its own back-and-forth with banners in the first place. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
