Thanks for the abundant generosity of patience, but I didn't mean that I wanted to add a note to the text of the I-D, there's been enough delay and I'm excited to see this progress. I just meant "add a note" in my e-mail ;-) Though I do like your terse note, it's right to the point.
On Sun, Jan 14, 2018 at 9:47 PM, Eric Rescorla <e...@rtfm.com> wrote: > Hi Colm, > > Thanks for your note. This seems straightforward to handle before IETF-LC. > > Maybe something like: > "Note: many application layer protocols implicitly assume that replays are > handled at lower levels. Tailure to observe these precautions may exposes > your application to serious risks which are difficult to assess without a > thorough top-to-bottom analysis of the application stack"? > > -Ekr > > > On Sun, Jan 14, 2018 at 12:15 PM, Colm MacCárthaigh <c...@allcosts.net> > wrote: > >> >> Back during the previous last call, I felt really guilty about bringing >> up the 0-RTT stuff so late. Even though it turned out that middle boxes >> turned out to be a bigger problem to deal with anyway, I just want to say >> that I'm really grateful for the 0-RTT related changes in the document and >> for the time and effort that went into all that. I think those changes are >> sufficient to make a TLS1.3 implementation that handles 0-RTT in a >> forward-secret, secure and safe way. The changes represent a good >> compromise between having a secure state and supporting vendors who want to >> be a bit more loose because their application environment can tolerate it >> and forward secrecy is not as valuable to their users. Thanks especially to >> ekr for inventing the fixes, for stewarding the clarifications, and for >> being awesome about it. >> >> At the same time, I just want to add a small note of caution to vendors; >> if you're going to accept 0-RTT, trying to cut corners by tolerating >> replays - even a little, is really likely to bite you! I've found even more >> examples of application protocols and web protocols that implement >> transactions. Also, if the secrecy of trillions and trillions of users web >> requests are going to rest on how well session ticket encryption keys are >> managed, protected, rotated and revoked, we really owe it to users to come >> up with some collective guidance for vendors on how to do that well. >> >> >> On Fri, Jan 12, 2018 at 9:10 PM, Sean Turner <s...@sn3rd.com> wrote: >> >>> All, >>> >>> This is the 3rd working group last call (WGLC) announcement for >>> draft-ietf-tls-tls13; it will run through January 26th. This time the WGLC >>> is for version -23 (https://datatracker.ietf.org/ >>> doc/draft-ietf-tls-tls13/). This WGLC is a targeted WGLC because it >>> only address changes introduced since the 2nd WGLC on version -21, i.e., >>> changes introduced in versions -22 and -23. Note that the editor has >>> kindly included a change log in s1.2 and the datatracker can also produce >>> diffs (https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-tls13-21&u >>> rl2=draft-ietf-tls-tls13-23). In general, we are considering all other >>> material to have WG consensus, so only critical issues should be raised >>> about that material at this time. >>> >>> Cheers, >>> >>> spt >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >> >> >> -- >> Colm >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
