EKR, If you are going to add this (seems like a reasonable idea to me) please note the minor typo of “tailure”, which I presume should be failure.
Tim Sent from Email+ secured by MobileIron ________________________________ From: "Colm MacCárthaigh" <c...@allcosts.net<mailto:c...@allcosts.net>> Date: Sunday, January 14, 2018 at 2:42:04 PM To: "Eric Rescorla" <e...@rtfm.com<mailto:e...@rtfm.com>> Cc: "" <tls@ietf.org<mailto:tls@ietf.org>> Subject: Re: [TLS] 3rd WGLC: draft-ietf-tls-tls13 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<mailto: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<mailto: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<mailto: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&url2=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<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls -- Colm _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
