Hi Colm, On Mon, Feb 19, 2018 at 11:13:44AM -0800, Colm MacCárthaigh wrote: > Since this IETF-LC/IESG process is a good chance to get a sanity check, I'd > like to boil down what I think are the nits and risks with 0-RTT, and if > others want to weigh in they can. I'll state my own position at the bottom. Thanks for this summary and review; I think it's well-said. > Broadly, I think there are three issues with 0-RTT: > [...] > At the same time though, most vendors have stated that they don't plan to > do that and instead have designed around limited replay time windows, > non-transactional strike registers, and non-forward secure tickets. This is > what I expect to see deployed, and already see with some TLS1.3 deployment > experiments. TLS1.3 could be more restrictive here; limiting the size of I don't disagree. It might be helpful to have a conslidated list of references for the vendor statements, so we can get a more clear picture of where to set our expectations. Though of course I do not insist that you assemble one, and I do not want my comment to be seen as detracting from your review overall. > session tickets to smaller than the size of session state would effectively > forbid any kind of session encoding which would force the issue, but > several vendors are against it because it doesn't align with current > practices and it incurs the cost of server-size caching. For balance, in > the last year I have heard from most vendors that they do plan to implement > some anti-replay mitigation though, beyond the simple time-windowing, which > goes a way to protecting users from throttle limits. > [...] > > But my more important reason for supporting is that overall TLS1.3 is much > much better than TLS1.2, including in regards to forward-secrecy, which is > now guaranteed for all non-0RTT data. I still believe that it will > meaningfully increase the overall security posture for the internet, and > I'm super excited to get it out and for users to be getting the benefits. > TLS has always been a bit of a mess, it's not as clean as something > designed by a single voice focused on modern cryptographic best-practices, > but 1.3 does a lot of good cleaning up. Shipping 1.3 doesn't mean things > can't be improved further, and delay inflicts 1.2 and lower versions on > users for even longer. So let's go! Well said! -Benjamin > > On Mon, Feb 19, 2018 at 7:58 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@xxxxxxxxx> wrote: > > > Dear Yuhong, > > > > As the sponsoring Area Director, my job is to take the draft forward > > as was determined by working group consensus. Like Stephen, I'm also > > not particularly happy about the choice to leave in 0-RTT, but I have > > to support it as a WG decision. Whatever the version number in the > > ServerHello decision is from the WG, I will support that decision. > > The ServerHello decision doesn't really fall into the, "arms race" as > > you put it. More on that in another thread. > > > > Best regards, > > Kathleen > > > > On Thu, Feb 15, 2018 at 9:04 PM, Yuhong Bao <yuhongbao_386@xxxxxxxxxxx> > > wrote: > > > I wonder what is IESG's opinion on the TLS arms race with middleboxes. > > > Yes, I am talking about moving the version number in the ServerHello. > > > > > > ________________________________________ > > > From: TLS <tls-bounces@xxxxxxxx> on behalf of The IESG < > > iesg-secretary@xxxxxxxx> > > > Sent: Thursday, February 15, 2018 1:13:48 PM > > > To: IETF-Announce > > > Cc: draft-ietf-tls-tls13@xxxxxxxx; tls-chairs@xxxxxxxx; tls@xxxxxxxx > > > Subject: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport > > Layer Security (TLS) Protocol Version 1.3) to Proposed Standard > > > > > > > > > The IESG has received a request from the Transport Layer Security WG > > (tls) to > > > consider the following document: - 'The Transport Layer Security (TLS) > > > Protocol Version 1.3' > > > <draft-ietf-tls-tls13-24.txt> as Proposed Standard > > > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final > > > comments on this action. Please send substantive comments to the > > > ietf@xxxxxxxx mailing lists by 2018-03-01. Exceptionally, comments may > > be > > > sent to iesg@xxxxxxxx instead. In either case, please retain the > > beginning of > > > the Subject line to allow automated sorting. > > > > > > Abstract > > > > > > > > > This document specifies version 1.3 of the Transport Layer Security > > > (TLS) protocol. TLS allows client/server applications to communicate > > > over the Internet in a way that is designed to prevent eavesdropping, > > > tampering, and message forgery. > > > > > > > > > > > > > > > The file can be obtained via > > > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ > > > > > > IESG discussion can be tracked via > > > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/ > > > > > > The following IPR Declarations may be related to this I-D: > > > > > > https://datatracker.ietf.org/ipr/2900/ > > > > > > > > > > > > The document contains these normative downward references. > > > See RFC 3967 for additional information: > > > rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 > > (Informational - IETF stream) > > > > > > > > > > > > _______________________________________________ > > > TLS mailing list > > > TLS@xxxxxxxx > > > https://www.ietf.org/mailman/listinfo/tls > > > > > > _______________________________________________ > > > TLS mailing list > > > TLS@xxxxxxxx > > > https://www.ietf.org/mailman/listinfo/tls > > > > > > > > -- > > > > Best regards, > > Kathleen > > > > > > > -- > Colm
