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

> 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.

By application here I mean website html / JS which creates the http request and triggers the agent (browser) into making an http request or in the case of a mobile app the application code that calls the http library.

Currently the only way to express retry behavior in HTTP is by the method (i.e. whether it is idempotent or not), which as you pointed out may have unfortunate side effects, since it is not explicit. The proposal (at least one of them) is to add an explicit way to express retry safety in HTTP as an additional request property similar to method. This can be used by the agent (browser or http library) to decide whether or not to use 0-RTT for the http data. I'll link to it in this thread once it's posted.

Subodh

________________________________
From: Watson Ladd [watsonbladd@gmail.com]
Sent: Monday, March 14, 2016 11:19 AM
To: Subodh Iyengar
Cc: tls@ietf.org
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Mar 14, 2016 11:04 AM, "Subodh Iyengar" <subodh@fb.com<mailto:subodh@fb.com>> 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 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.

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 [tls-bounces@ietf.org<mailto:tls-bounces@ietf.org>] on behalf of Viktor Dukhovni [ietf-dane@dukhovni.org<mailto:ietf-dane@dukhovni.org>]
> Sent: Monday, March 14, 2016 10:36 AM
> To: tls@ietf.org<mailto:tls@ietf.org>
> Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
>
> > On Mar 13, 2016, at 7:14 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>> 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.
>
> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org<mailto:TLS@ietf.org>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=WfBqzUVkz2aHPj_ZubNS486Z0f_mB52duCvuRK1GtSQ&s=qKrC1QXmZHVEq84oPhjuABuCzx4hwadP6c9TuTlMJx8&e=
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org<mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=h5hXdolUsOp-qMk9C5d9e49kAwBj2OHqfGDHj4_lzxI&s=LqRbrd9Sz2Gi0TTubeKQmOOgbdl5cj1g8ZnS6kPcOHA&e=>