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

Subodh Iyengar <> Mon, 14 March 2016 18:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 46F4112D5DA for <>; Mon, 14 Mar 2016 11:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Status: No, score=-2.721 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_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 uSmmQcGpoDV9 for <>; Mon, 14 Mar 2016 11:04:16 -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 9298512D6AB for <>; Mon, 14 Mar 2016 11:04:16 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id u2EHsGnj025198 for <>; Mon, 14 Mar 2016 11:04:11 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=MYco65bClqU7QH3fFfzbkejCJdKjvW/p3OwRP7OnRtg=; b=O42a/P1c7CXkr0t2laVEGi6R4OU+xM3F5tXbkQ+gTVG3h7RyUkHQ61x/i72nRNG8P2Y3 u7Yxthy1p7BDktZ9sI3BerDCCPw8PbUTndrYl0hAYNDVf4R3GGkS/6YcAYAqRrL+98hi MOyggORxKoPe08Si08BVWUhN4f19YnPACaM=
Received: from ([]) by with ESMTP id 21mfne3pyx-6 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT) for <>; Mon, 14 Mar 2016 11:04:11 -0700
Received: from ([]) by ([fe80::9886:b2c2:db18:5ba7%12]) with mapi id 14.03.0248.002; Mon, 14 Mar 2016 11:04:09 -0700
From: Subodh Iyengar <>
To: "" <>
Thread-Topic: [TLS] analysis of wider impact of TLS1.3 replayabe data
Thread-Index: AQHRfRmFajTdv10Pjk6fDp6jA/HnJp9ZqziA//+MDMk=
Date: Mon, 14 Mar 2016 18:04:07 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: <>
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 18:04:18 -0000

I think the discussion about not understanding the implications of replayability is not correct. We are already in the situation where client data is replayable. For example if a mobile app encounters an HTTP error, it will probably retry the request throwing caution to the wind about replayability. Many popular HTTP libraries already do this very actively. In this scenario, even TLS1.2 replayability gurantees fall apart. At Facebook, we have several popular mobile applications and have plenty of experience dealing with retries. 

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. 

Discussions of replayability in the void is impossible. There is no way TLS1.3 is going to know all the use cases for replayability. That is an application layer decision. Thus we should have proposals at the application layer as well to express these properties to the transport layer, and we have one proposal for this which we're going to submit soon to HTTP WG. For example in the case of http, an application should express to the lower layers that the request that it is sending out is retry safe and that it is taking care of it. 

Developers are adults too. We can prevent them from shooting themselves in the foot by providing secure OFF by default option, but completely removing the option from them expressing these application properties to the underlying transport layer seems like treating them like children. I would hate to see 0-RTT removed from the spec. This is something we at Facebook are looking forward to using and want to use immediately in browsers once it is available.


From: TLS [] on behalf of Viktor Dukhovni []
Sent: Monday, March 14, 2016 10:36 AM
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

> On Mar 13, 2016, at 7:14 AM, Stephen Farrell <> wrote:
> So, can people suggest ways in which we can figure out the impact
> of replayable data across all the many uses of TLS?

For idempotent (more strongly side-effect free) lookup protocols, 0-RTT makes
good sense.  There is no need for replay protection in the absence of
side-effects.  Web browsers are not the only use-case for TLS.

Similarly, in SMTP with STARTTLS the client's first data payload is a repeat
of an EHLO command that was already sent in the clear!  So one might for example
send the client's EHLO as 0-RTT replayable data.  Of course SMTP servers that
support 0-RTT data don't exist yet, but they may once 0-RTT becomes widely
available in SSL/TLS toolkits.


TLS mailing list