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

On Mar 14, 2016 11:04 AM, "Subodh Iyengar" <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] on behalf of Viktor Dukhovni [
ietf-dane@dukhovni.org]
> Sent: Monday, March 14, 2016 10:36 AM
> To: 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>
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
>
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
> https://www.ietf.org/mailman/listinfo/tls