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. 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. 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;-)
Attachment:
0x7B172BEA.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
