As promised: https://github.com/tlswg/tls13-spec/pull/1005
Note: I may have to do a little post-landing cleanup, but I wanted to get people's senses of the text ASAP. Comments welcome. -Ekr On Wed, May 3, 2017 at 8:21 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > On Wed, May 3, 2017 at 8:20 PM, Colm MacCárthaigh <c...@allcosts.net> > wrote: > >> >> >> On Wed, May 3, 2017 at 8:13 PM, Eric Rescorla <e...@rtfm.com> wrote: >> >>> I made some proposals yesterday >>> (https://www.ietf.org/mail-archive/web/tls/current/msg23088.html). >>> >>> Specifically: >>> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining >>> both session-cache and strike register styles and the merits of each. >>> >>> 2. Document 0-RTT greasing in draft-ietf-tls-grease >>> >>> 3. Adopt PR#448 (or some variant) so that session-id style >>> implementations >>> provide PFS. >>> >>> 4. I would add to this that we recommend that proxy/CDN implementations >>> signal which data is 0-RTT and which is 1-RTT to the back-end (this was >>> in >>> Colm's original message). >>> >> >> This all sounds great to me. I'm not sure that we need (4.) if we have >> (1.). I think with (1.) - recombobulating to a single stream might even be >> best overall, to reduce application complexity, and it seems to be what >> most implementors are actually doing. >> >> I know that leaves the DKG attack, but from a client and servers >> perspective that attack is basically identical to a server timeout, and >> it's something that systems likely have some fault tolerance around. It's >> not /new/ broken-ness. >> > > Heh. Always happy to do less writing. > > Thanks, > -Ekr > > >> >> >>> Based on Colm's response, I think these largely hits the points he made >>> in his original message. >>> >>> There's already a PR for #3 and I'll have PRs for #1 and #4 tomorrow. >>> What would be most helpful to me as Editor would be if people could >>> review >>> these PRs and/or suggest other specific changes that we should make >>> to the document. >>> >> >> Will do! Many thanks. >> >> -- >> Colm >> > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
