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

Watson Ladd <> Mon, 14 March 2016 18:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9383D12D553 for <>; Mon, 14 Mar 2016 11:19:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 K2jUYZUOM8ne for <>; Mon, 14 Mar 2016 11:19:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2057A12D58A for <>; Mon, 14 Mar 2016 11:19:05 -0700 (PDT)
Received: by with SMTP id c3so219565959vkb.3 for <>; Mon, 14 Mar 2016 11:19:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=BWSR/axRsxt2a21/cjj7AmYH01399yv6XiFPp6aISJs=; b=NoeeLeAvkfd8hKJ67TPHijObwdV6VvmaGYtd5svmCBnKkyxJfI1cQgVwy8jGPjAb5C 300HxVj9WxjkgioaibtEA3+o2+pOy+kvXFwXKijAHKSMd2J79ui1oUfKnJpfEl381lRl 4pu/lpuGIiqLfuA4lAMfVyn4JmkkXyFxukdN41H/IMXVlayu5unsZiqFLuGIJmef8D2x F8+ouP3GkaZHMA5LQSfqwRj/EcqX6QYwdwWi5uoYOLPF1wc9qrO88JaCuOCtfKfQhYkF SY0HEF8/HwzqAnQTZa1sWqNBbVeMAfPXmLCfTcC+gisZCKfdRhRecvxn6NNNc2wPdXrg GGsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=BWSR/axRsxt2a21/cjj7AmYH01399yv6XiFPp6aISJs=; b=gCFeLBrmXSOvAw2dXjlkkQNYpdJGHFb/CxTkzVwoMMosg1gQxr5PtWcYMf19dpD36i pHyXhmyuTUo768wFFPNlKsEYY4QkSIhiBsFcjHbEfdD1qLJdqnveNDoBKZL2Lfjfywgq 3PBa++wRKp7tQDfTAQ11hOX2U4TvXxZB0TcKmNillYLtGgkyeSK7FJFXFc+Cd9tD5Tx+ puDot/8z6qSoor+LuHrjJlMmrmYpd5xxhFaXF8AznIjn3jXjJzwV9SNveCaSiYj6ZI2B 1CkIDRoQFzlBoIO9EaOwFkdRUX1Q4BtD/D6Z9O3ZEZIoWDFOAAL8bdu5Huhu413QQMA5 Y3og==
X-Gm-Message-State: AD7BkJLLldmq4za52WkRlzwBPYeeu3h1Bb8Q4+Q3Pe5twvTJg8Vcl1xHJAu8MKAsIzsbTh2Fu2QinFXGFIYVww==
MIME-Version: 1.0
X-Received: by with SMTP id 190mr27097824vkk.51.1457979544052; Mon, 14 Mar 2016 11:19:04 -0700 (PDT)
Received: by with HTTP; Mon, 14 Mar 2016 11:19:03 -0700 (PDT)
Received: by with HTTP; Mon, 14 Mar 2016 11:19:03 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Mon, 14 Mar 2016 11:19:03 -0700
Message-ID: <>
From: Watson Ladd <>
To: Subodh Iyengar <>
Content-Type: multipart/alternative; boundary=001a11440176d029ca052e065044
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:19:07 -0000

On Mar 14, 2016 11:04 AM, "Subodh Iyengar" <> wrote:
> 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.

Do they in fact fall apart? Or do libraries providing HTTP services
carefully document their replay and reordering protections, and application
developers carefully consider how to deal with replays?

Many websites still say do not hit refresh or you will be charged twice.
0RTT enables reordering replay data with interesting effects, and so is
distinct from doing background updates while changing the UI immediately in
that requests can happen again adversarially.
> 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
> 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.

Is the "application" HTTP or a website? Many websites got bitten by nginx
changing how it treated certain retries due to ordering interactions. The
canonical example is a DELETE and a POST.
> Subodh
> ________________________________________
> From: TLS [] on behalf of Viktor Dukhovni []
> Sent: Monday, March 14, 2016 10:36 AM
> To:
> Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
> > On Mar 13, 2016, at 7:14 AM, Stephen Farrell <>
> >
> > 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
> 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
> of an EHLO command that was already sent in the clear!  So one might for
> send the client's EHLO as 0-RTT replayable data.  Of course SMTP servers
> support 0-RTT data don't exist yet, but they may once 0-RTT becomes widely
> available in SSL/TLS toolkits.
> --
>         Viktor.
> _______________________________________________
> TLS mailing list
> _______________________________________________
> TLS mailing list