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

Stephen Farrell <> Mon, 19 February 2018 22:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75F4C126BF6; Mon, 19 Feb 2018 14:04:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.311
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wQfdUx27Wu8k; Mon, 19 Feb 2018 14:04:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 74E22129502; Mon, 19 Feb 2018 14:04:48 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A784CBE4C; Mon, 19 Feb 2018 22:04:46 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LaYG13xT9mN9; Mon, 19 Feb 2018 22:04:41 +0000 (GMT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 0A80BBDCC; Mon, 19 Feb 2018 22:04:41 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; 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 <>, Kathleen Moriarty <>
Cc: "" <>, "" <>, "" <>, "" <>
References: <> <>
From: Stephen Farrell <>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Message-ID: <>
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: <>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="jlEL1L6Vn4dUVZi4UPZBCJhNuaKPR7m53"
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: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.


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;-)