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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D71C12D79B for <>; Mon, 14 Mar 2016 14:14:52 -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 Nxyq3B0BEvt7 for <>; Mon, 14 Mar 2016 14:14:50 -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 9F48A12D78E for <>; Mon, 14 Mar 2016 14:14:50 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id u2ELBIHi015797; Mon, 14 Mar 2016 14:14:48 -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=FrtZJvazL6ALLhvvf36IHO/mnKDPSaldKAEvkDeXPw0=; b=gwHQy5U1BvWfSMZ4SKj+C+9rbJfYhc0kk/tmcb/2yVuqD/iqPA3DkvVvwJz+V0JZrdq7 A0MxNaudSoxZ4rGK2W1gng7GaQhaGjHNB50BgXMhdckPEBOFw3oWGNGakkJL/swni2ZT aJzpWesC6WcVXWG4BmbUx+U01qmxcaIyCZg=
Received: from ([]) by with ESMTP id 21p4rtr31q-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Mar 2016 14:14:48 -0700
Received: from ([]) by ([fe80::9886:b2c2:db18:5ba7%12]) with mapi id 14.03.0248.002; Mon, 14 Mar 2016 14:14:46 -0700
From: Kyle Nekritz <>
To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= <>, Subodh Iyengar <>
Thread-Topic: [TLS] analysis of wider impact of TLS1.3 replayabe data
Thread-Index: AQHRfRmI7Upjw+kKz0W8CBQxY0euOZ9ZqziAgAAHu4CAAAcKgP//k0AQ
Date: Mon, 14 Mar 2016 21:14:46 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_8A79BFEDF6986C46996566F91BB63C860D653797PRNMBX021TheFac_"
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_06:, , 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 21:14:52 -0000

If a client nonce cache is used then the threat is essentially the same as with ordinary retries.

As far as forward secrecy, yes, the 0-RTT data loses some forward secrecy. I think this is a reasonable trade off for a lot of use cases. Currently, TLS 1.2 implementations commonly use session tickets to improve performance. This actually sacrifices more forward secrecy (the whole connection, instead of just the initial client->server 0-RTT flight), for a smaller performance gain (it doesn’t even save a roundtrip compared with TLS false start). 0-RTT has a smaller forward secrecy cost and larger benefit compared to session tickets in use today.


From: TLS [] On Behalf Of Colm MacCárthaigh
Sent: Monday, March 14, 2016 2:29 PM
To: Subodh Iyengar <>
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Mon, Mar 14, 2016 at 11:04 AM, Subodh Iyengar <<>> wrote:
Like Kyle mentioned the thing that 0-RTT adds to this is infinite replayability. As mentioned in the other thread we have ways to reduce the impact of infinite replayable data for TLS, making it reasonably replay safe.

That too is a mis-understanding. The deeper problem is that a third party can do the replay, and that forward secrecy is gone for what likely is sensitive data. Neither is the case with ordinary retries.