Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Mon, 19 February 2018 22:58 UTC
Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B832126CC4; Mon, 19 Feb 2018 14:58:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Nayh7asyDy01; Mon, 19 Feb 2018 14:58:36 -0800 (PST)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECCF9126BFD; Mon, 19 Feb 2018 14:58:35 -0800 (PST)
Received: by mail-qt0-x236.google.com with SMTP id d26so14200480qtk.10; Mon, 19 Feb 2018 14:58:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Sjix5KW/TOoi5gV2yzMod1yr5o+I4bxUyjab9o7igDU=; b=DiyLXcTO0/FcfiJt4TEqIUSsN/NJCDBZMtj3YeD7GYdNSjx2kOaVBysW6QYN24GGKk nIkFUqjs/zrYrGakDRgxX8dldX1p49NEkBh1oPLF8ty7tDrGz0FFHP7ZKjQNjl9IH0U/ e/ez+4x9L3Rxi+qb1XeUII9Xu9b8br0KpQvpP18ULRDMqinNfVZRi7zlQCsickAevDHW PHdN6/uUdLZ0YQXFCig5VEzPrj/OY6Ll6WvYOrpvAfrLT7ZcL6JOP68kYiOZztBqtNBe ITkXIPvx693TAPutX4v4qvMuvtbEKa5sWqlTKt0bCQcp4/+f1YYxJzLv2kr29zpq7YAw 5cYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Sjix5KW/TOoi5gV2yzMod1yr5o+I4bxUyjab9o7igDU=; b=G/imT0tyK0fZW8En8NlFcRaxJxJJOSlI5qMDakyYu2RiJin6ofEQmdq3IyFt+MU0TZ pIhMDo4i7GFpYiT0FFeypfbvoxrWIMRC/G1+2DiyffHhnDOnVlzEHIfLrpPWEMzLo/LK UsVEOKmRewQ2VozB8ieCH29u1xpQt2PTH21YpAcYKndgraeMGa5GvoUH5q/1Ijw58QnE qF/18ZeIQgICOOPgyOiu8kuaS+Y3JIxWkgby3DC9kLHe9cJ30ITF9OE3E5dNWlB7JxCB 9JM+GJ2eajoUmqYqMRBGSFMwK7P1lMSwoKiD1hctbhs8Oa1pqKIRk4m7U/TdRJDoaCSj MQmQ==
X-Gm-Message-State: APf1xPBx1EJec6idCS/ZW8hR2noZREqkpMQCFnbDg+pBY1/0NX4/2h1k IC4UqbJA43va3A3hkdBWSOSnVst5
X-Google-Smtp-Source: AH8x224DYht0XgKBmkLvDsjeDAbTaSMUkzo886JwSCfKyuPB2SoOB/X8WIieYSKBpTK9xjsNWjdbFw==
X-Received: by 10.200.50.251 with SMTP id a56mr27137198qtb.13.1519081114675; Mon, 19 Feb 2018 14:58:34 -0800 (PST)
Received: from [192.168.1.219] (209-6-112-84.s338.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.112.84]) by smtp.gmail.com with ESMTPSA id g8sm16397291qth.73.2018.02.19.14.58.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Feb 2018 14:58:33 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
Subject: Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Mailer: iPhone Mail (15D60)
In-Reply-To: <4e408208-f306-acd9-5e4f-f0558f087bed@cs.tcd.ie>
Date: Mon, 19 Feb 2018 17:58:32 -0500
Cc: Colm MacCárthaigh <colm@allcosts.net>, "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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6B37A1DD-89AB-4978-82BA-F912A1F0EC07@gmail.com>
References: <CAHbuEH45PYDuhwFPhv-ybDY6LyzsBhfdEwhJPFLQg9b+ndNK9w@mail.gmail.com> <CAAF6GDdsHW4ynWm15cMgL3BRkJw5xFshhQVO3S47MQD8fVMMag@mail.gmail.com> <4e408208-f306-acd9-5e4f-f0558f087bed@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/5G8k_wK0IA3TIx6pLsV4LsGTr18>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Feb 2018 22:58:39 -0000
Sent from my mobile device > On Feb 19, 2018, at 5:04 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> 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@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;-) > <0x7B172BEA.asc>
- Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt… Yuhong Bao
- 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