Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 19 February 2018 22:04 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F4C126BF6; Mon, 19 Feb 2018 14:04:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQfdUx27Wu8k; Mon, 19 Feb 2018 14:04:56 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E22129502; Mon, 19 Feb 2018 14:04:48 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A784CBE4C; Mon, 19 Feb 2018 22:04:46 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaYG13xT9mN9; Mon, 19 Feb 2018 22:04:41 +0000 (GMT)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0A80BBDCC; Mon, 19 Feb 2018 22:04:41 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1519077881; bh=ZnibS3jXG5UZgyaRX2YNaBT5XhuVreznIenryZhOgL0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=zSwfRZjLT0qaimR89OqYtYcnMFyYSjmklOPtl8OVmkhYu3ip01XnMQq7TDPRy6DP1 aEDI0rplQBdXeexzxllDy2ulNMD8CgthY/d4qtZe2AS6Lb+KapU1bVkacyVF5b/nHI 8ASjZZaWatH6JZUUZPE85VcxVvaesWLq4tk35VE0=
To: Colm MacCárthaigh <colm@allcosts.net>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Cc: "draft-ietf-tls-tls13@ietf.org" <draft-ietf-tls-tls13@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "tls-chairs@ietf.org" <tls-chairs@ietf.org>, "tls@ietf.org" <tls@ietf.org>
References: <CAHbuEH45PYDuhwFPhv-ybDY6LyzsBhfdEwhJPFLQg9b+ndNK9w@mail.gmail.com> <CAAF6GDdsHW4ynWm15cMgL3BRkJw5xFshhQVO3S47MQD8fVMMag@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Message-ID: <4e408208-f306-acd9-5e4f-f0558f087bed@cs.tcd.ie>
Date: Mon, 19 Feb 2018 22:04:40 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CAAF6GDdsHW4ynWm15cMgL3BRkJw5xFshhQVO3S47MQD8fVMMag@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="jlEL1L6Vn4dUVZi4UPZBCJhNuaKPR7m53"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_ypnN4NE47xjZgx8PnLpg9UJWjk>
Subject: Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Feb 2018 22:05:00 -0000
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@gmail.com> 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@hotmail.com> >> 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@ietf.org> on behalf of The IESG < >> iesg-secretary@ietf.org> >>> Sent: Thursday, February 15, 2018 1:13:48 PM >>> To: IETF-Announce >>> Cc: draft-ietf-tls-tls13@ietf.org; tls-chairs@ietf.org; tls@ietf.org >>> 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@ietf.org mailing lists by 2018-03-01. Exceptionally, comments may >> be >>> sent to iesg@ietf.org 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@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> >> >> >> -- >> >> Best regards, >> Kathleen >> >> > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > 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;-)
- [TLS] Last Call: <draft-ietf-tls-tls13-24.txt> (T… The IESG
- Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt… Yuhong Bao
- Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt… Sean Turner
- Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt… Kathleen Moriarty
- Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt… Colm MacCárthaigh
- Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt… Benjamin Kaduk
- Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt… Kathleen Moriarty
- Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt… Stephen Farrell
- Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt… Kathleen Moriarty
- Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt… Benjamin Kaduk
- Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt… Sean Turner
- Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt… Sean Turner
- Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt… Benjamin Kaduk
- Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt… Martin Thomson
- Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt… Sean Turner
- Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt… Martin Thomson
- Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt… Sean Turner