Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

Kyle Nekritz <> Mon, 14 March 2016 14:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 07EE212DAEF for <>; Mon, 14 Mar 2016 07:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 JsvtcPzm_ai3 for <>; Mon, 14 Mar 2016 07:59:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B2C4512DC72 for <>; Mon, 14 Mar 2016 07:52:51 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id u2EEqF5R031812; Mon, 14 Mar 2016 07:52:50 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=Klm43Emu6jTTKBA9KlM/nykAXT9MTr9akHLL/x9d55E=; b=mC6KWJyzfW0RNShH/Ezb7uFrfL6ZUsP49bVK0eXTE+vHr5/tkty1I6aRVS2ldUr7rPpV VCOYfg7QJybMZhtKenqAY7c3BFbOui6CZ+qTTZoaiU1kZU9fFeY1DM62kWoF/fO1H2nB ORuFaYkjMishq61RtM8qNGOESFTYOhdROAM=
Received: from ([]) by with ESMTP id 21nycur111-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Mar 2016 07:52:50 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 14 Mar 2016 07:52:49 -0700
Received: from ([]) by ([fe80::6964:6730:1d3b:b80c%13]) with mapi id 14.03.0248.002; Mon, 14 Mar 2016 07:52:48 -0700
From: Kyle Nekritz <>
To: Bill Cox <>, Scott Schmit <>
Thread-Topic: [TLS] analysis of wider impact of TLS1.3 replayabe data
Thread-Index: AQHRfRmI7Upjw+kKz0W8CBQxY0euOZ9YWGEAgAAQgoD//96AYA==
Date: Mon, 14 Mar 2016 14:52:47 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_8A79BFEDF6986C46996566F91BB63C860D652CCCPRNMBX021TheFac_"
MIME-Version: 1.0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-14_05:, , signatures=0
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
X-Mailman-Version: 2.1.17
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, 14 Mar 2016 14:59:32 -0000

I think that idempotency is a relatively straightforward idea, it seems reasonable to trust that the application layer will only send 0-RTT data that is idempotent in terms of server-side state. I also don't think it's that much different than the current state of TLS. Providing strict replay protection over an unreliable network link requires that requests are never retried in the case of network failure - which is not practical in most applications. If the application doesn't already have some way to provide idempotency to requests that change state, it's likely already in a bad place (see

However, to safely use 0-RTT (in the current draft), the 0-RTT data needs a stricter property than idempotency, it needs to be completely replay-safe. Unlike TLS now, where the opportunity for replay is linear in relation to the number of times a client is willing to retry a request, an attacker can replay a request an unlimited number of times.

There's two capabilities a passive eavesdropper gains from this that concern me the most:
    1) Changes to the response's length and timing can be observed over time
    2) The response's timing can be statistically analyzed (since the request can be replayed an unlimited number of times)
Mitigating these at the application layer seems much harder, if not impossible, to get right.

Adding a client time indicator (as I suggested in the other thread) makes this harder, but it certainly doesn't solve either problem. A server-side client nonce cache does solve these problems, which I think may be required to use 0-RTT safely. That said, I echo Bill's comments about the need for 0-RTT in TLS 1.3. Speed is very important.


From: TLS [] On Behalf Of Bill Cox
Sent: Sunday, March 13, 2016 6:23 PM
To: Scott Schmit <>
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, Mar 13, 2016 at 2:23 PM, Scott Schmit <<>> wrote:

So why are we adding a protocol optimization known from the start to be
insecure (or less secure than you'd expect from using a PFS cipher

If you require PFS with resolution on the order of seconds to minutes rather than hours to days, you probably do not want to use tickets either.  The ticket decryption key rotation schedule limits PFS.  0-RTT resumes do not make this worse.

What percentage of servers that have a perceived need for 0-RTT will be
able to securely use and benefit from this feature as their
infrastructure is actually implemented?

Well, Google already sees a significant fraction.  Going back to 1-RTT would be a significant downgrade.

If almost everyone should turn it off, why are we including it?

Almost every small site on the Internet should turn it off, but the large sites that want to enable it could make up a large fraction of all traffic.

Most server admins won't be reading the TLSv1.3 spec.  They're going to
see "shiny feature added specifically in this version that makes it
faster!" with *maybe* a warning that there are risks, which they'll
dismiss because "if it was so insecure, they wouldn't have included it
in the protocol in the first place."  Unless 0-RTT can be fixed, it
looks like an attractive nuisance.

I agree.  Instead of dropping 0-RTT, I think we should make it easy for admins to learn about what is involved in using 0-RTT in ways we believe are secure.  The two modes I am aware of that are potentially as secure as TLS 1.2 session resumption are:

- Do 0-RTT session resumption using a session cache, using the ticket as the session ID.  This should have the same security as TLS 1.2 resume, right?
- At the HTTP app layer, make all requests that change state transaction based with unique transaction numbers, so replay attacks fail to change server state.  Done successfully, this should be more secure than TLS 1.2 resumption, shouldn't it?

Are we aware of other secure ways to do 0-RTT?