Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

Kathleen Moriarty <> Mon, 19 February 2018 22:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B832126CC4; Mon, 19 Feb 2018 14:58:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Nayh7asyDy01; Mon, 19 Feb 2018 14:58:36 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ECCF9126BFD; Mon, 19 Feb 2018 14:58:35 -0800 (PST)
Received: by with SMTP id d26so14200480qtk.10; Mon, 19 Feb 2018 14:58:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id a56mr27137198qtb.13.1519081114675; Mon, 19 Feb 2018 14:58:34 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id g8sm16397291qth.73.2018. (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)
From: Kathleen Moriarty <>
X-Mailer: iPhone Mail (15D60)
In-Reply-To: <>
Date: Mon, 19 Feb 2018 17:58:32 -0500
Cc: Colm MacCárthaigh <>, "" <>, "" <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Stephen Farrell <>
Archived-At: <>
Subject: Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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.


Thank you,

> 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 (
>> ), 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" (
>> 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:
>> .
>> 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" ( 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 <
>>> 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 <>
>>> 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 <> on behalf of The IESG <
>>>> Sent: Thursday, February 15, 2018 1:13:48 PM
>>>> To: IETF-Announce
>>>> Cc:;;
>>>> 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
>>>> mailing lists by 2018-03-01. Exceptionally, comments may
>>> be
>>>> sent to 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
>>>> IESG discussion can be tracked via
>>>> The following IPR Declarations may be related to this I-D:
>>>> 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 mailing list
>>> --
>>> Best regards,
>>> Kathleen
>> _______________________________________________
>> TLS mailing list
> -- 
> 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>