Sent from my mobile device > On Feb 19, 2018, at 5:04 PM, Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote: > > > Just on the 0-RTT thing: > > As a non-fan of 0-RTT I agree with Colm's conclusion. (Nicely > argued too btw.) > > I do believe we'll live to regret 0-RTT when implementation > issues and unsuitable application uses emerge over time but > neither that nor general dislike of 0-RTT are IMO sufficient > reasons to hold TLS 1.3 at this point, given the benefits of > other aspects of TLS 1.3. > +1 on all of the above. > In addition, the fact of 0-RTT as an (in practice) unavoidable > part of TLS 1.3 and the implications of that were previously > raised with both the IESG and IAB in a fair amount of detail, > (about 1.5-2 years ago maybe but the issues are the same) and > IIRC at an IETF plenary as well, so this has been rehearsed > before the IETF already, even if not during a formal IETF LC. Agreed. Thank you, Kathleen > > Cheers, > S. > >> On 19/02/18 19:13, 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. >> >> Broadly, I think there are three issues with 0-RTT: >> >> 1) The TLS 1.3 draft allows for 0-RTT data, including things like >> requests and headers, to be replayed by attackers. >> >> 2) 0-RTT data, again including requests and headers, has no >> cryptographic guarantee of forward-secrecy and will likely be protected by >> symmetric session ticket encryption keys (STEK) that can be used quite >> broadly with no limits on re-use, rotation, and rely on vendors being able >> to share and revoke keys frequently and securely. Basically: If a vendors >> STEK is compromised, than an unbounded number of end-user requests and >> headers can be decrypted. This obviously defeats the goal of achieving >> forward secrecy. >> >> 3) While no working attack has been found, some cryptographers and >> protocol experts believe that the 0-RTT exchange is overly-complex and a >> source of risk. Kenny Paterson made the most prominent statement ( >> http://bristolcrypto.blogspot.com/2017/03/pkc-2017-kenny-paterson-accepting-bets.html >> ), but I've heard it echoed at several IACR events. It is definitely true >> that 0-RTT resumption complicates the TLS state machine and creates unusual >> conditions such as needing to restart messaging sequences. >> >> The TLS-WG was chartered with "aiming for one roundtrip for a full >> handshake and one or zero roundtrip for repeated handshakes. The aim is >> also to maintain current security features" ( >> https://datatracker.ietf.org/wg/tls/charter/). But with these 3 issues, >> there is a clearly a trade-off between security (the S in TLS) and speed. >> >> Issue 3 is matter of judgment; my personal judgement is that we will see >> implementation bugs due to state machine complexity, but there's no >> evidence that the cryptographic and protocol semantics are not robust. >> >> With regards to issues 1, and 2, the latest TLS draft makes it possible to >> achieve both of these aims. Through the use of single-use session tickets, >> it is possible to provide anti-replay and forward-secrecy properties for >> 0-RTT data. I'm grateful for the changes that were introduced for this. >> >> 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 >> 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. >> >> I am disappointed by the unfortunate preference for cost-saving over robust >> security. Good cryptography usually costs money, or else we'd still be >> using RC4. I do think that we will see security and correctness issues due >> to replays interacting with non-idempotent services and throttling >> configurations. While it's true that browsers can be made to replay >> requests already, there are many web and non-HTTP services that are >> certainly not tolerant of replays. Secondly, I think that it is inevitable >> that vendor security compromises will disclose troves of user requests, >> passwords, credit cards to decryption; but this is perhaps more of a >> nation-state-adversary level risk. Some more detail on attacks related to >> issues 1/ and 2/ is available in the security review of 0-RTT data: >> https://github.com/tlswg/tls13-spec/issues/1001 . >> >> >> After all of that, here's my own position: >> >> I strongly support the current TLS1.3 draft progressing to RFC status. I >> work at Amazon, where one of our leadership principles is "Disagree and >> Commit" (https://www.amazon.jobs/principles); the idea is that it's >> important to make yourself heard, but also to move forward and not be >> endlessly bogged down. I've been vocal about 0-RTT risks, and certainly >> heard and understood, and those concerns have been reflected in generous >> changes to the draft. I'm happy that it's possible to build a >> forward-secret, non-repayable 0-RTT implementation and that's what I'm >> doing. I wish everyone else would too, but that's not consensus; others >> have a different weighting for the trade-offs between speed, security and >> cost and those views are also legitimate. >> >> 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! >> >> >> 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 >>> >>> >> >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/tls >> > > -- > PGP key change time for me. > New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. > NewWithOld sigs in keyservers. > Sorry if that mucks something up;-) > <0x7B172BEA.asc>
