On Thu, May 4, 2017 at 2:13 PM, Eric Rescorla <e...@rtfm.com> wrote: > 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. >
Thanks for everyone's comments. I've updated the text to address many of them and made comments in Github where I decided not to do so. Can those who have read the previous version please take a look? I'd also like to merge PR#998. I haven't heard any real complaints about it and it's an improvement in any case. I'll await the chairs on that, though. -Ekr 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
