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

[Hubert Kario]

On Tuesday 22 March 2016 10:45:32 Martin Thomson wrote:
> On 22 March 2016 at 06:40, Hubert Kario  wrote:
> > Only in theory, in practice you can do most of the same things in
> > GET's as you can in POSTs.
> > 
> > in other words, basically web frameworks can be made to modify
> > server
> > state upon receiving GET request
> 
> Ahh yes, but it's not the *client's* fault if the server does that and
> the client tries multiple times.  The server is entirely responsible
> for the consequences of state modification at that point.

true, but that means that a blanket statement like "Sending GET requests 
in 0-RTT data is safe" is untrue.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

On 22 March 2016 at 06:40, Hubert Kario  wrote:
> Only in theory, in practice you can do most of the same things in GET's
> as you can in POSTs.
>
> in other words, basically web frameworks can be made to modify server
> state upon receiving GET request


Ahh yes, but it's not the *client's* fault if the server does that and
the client tries multiple times.  The server is entirely responsible
for the consequences of state modification at that point.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Hubert Kario]

On Monday 14 March 2016 12:12:51 Geoffrey Keating wrote:
> Colm MacCárthaigh  writes:
> > 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.
> 
> Just to expand on this:
> 
> HTTP GET is idempotent and so replayable, correct?  That is, if you
> send two GET requests in a row, you should get the same results, no
> changes should be caused on the server side, and the attacker learns
> nothing new, even if the attacker could not have issued the original
> GET.

Only in theory, in practice you can do most of the same things in GET's 
as you can in POSTs.

in other words, basically web frameworks can be made to modify server 
state upon receiving GET request

and even just the fact that the server thinks it has processed so many 
requests can be damaging (think timestamping service in which you pay 
per request)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

On Mon, Mar 14, 2016 at 11:38 AM, Bill Cox  wrote:

> On Mon, Mar 14, 2016 at 9:10 AM, Colm MacCárthaigh 
> wrote:
>
>> On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox  wrote:
>>
>>> As we all know, what matters most in security is the default mode.  I am
>>> suggesting making the default 0-RTT resumption mode stateful, with a
>>> documented session-ID (and let's bring back the timestamp, too, since we'll
>>> need it).
>>>
>>
>> Having state would make things much more robust; but rather than the
>> state being around the channel itself (the TLS session), would it be more
>> robust, and more flexible, for the state to be around the action? like some
>> kind of hint cookie.
>>
>
> It looks like server-side state is required to prevent replay.  I don't
> think any kind of token, cookie, or server-config can fix this.
>
>
>> One of the problems with session resumption is that in order to be replay
>> safe; the sequence number has to restart where it left off. That requires
>> some kind of transactional store, and if you're doing all of this for
>> latency, you may end up eating all of the wins there.
>>
>
> The new tickets can in theory end the debate over session caching vs
> session tickets, since they can be used for database lookups or contain an
> encrypted session state.  However, the spec does not document how to do
> session caching with tickets securely, which looks tricky.  In reality, if
> I were trying to build a speed and security sensitive site using TLS 1.3
> stateful 0-RTT resumption, I would probably do something like this:
>
> During the initial 1-RTT handshake:
> - create a ticket containing only the session ID, resumption count, and a
> session decryption key
> - encrypt the session cache entry with the session encryption key stored
> in the ticket
> - encrypt the ticket with a semi-static ticket encryption key, which I
> would rotate every few weeks
> - send the ticket to the client, which is after encryption is enabled on
> the connection
>
> During a 0-RTT resume handshake:
> - check for a cache hit, and drop to 1-RTT if not found
> - decrypt the ticket with ticket the semi-static ticket decryption key
> - decrypt the cached session state with the session key from the ticket
> - compare the resumption counts in the session state and ticket, and fall
> back to 1-RTT if they do not match
> - increment the resumption count
> - create a new session ticket with a new session encryption key and the
> updated resumption count
> - encrypt the session cache entry with the new session encryption key
> - send the client the new ticket
>
> I assume that it is legal to send a new ticket on a 0-RTT PSK resume, but
> it is not clear to me from the drawings in the spec.  It is not shown as an
> option.  This is required for secure stateful 0-RTT resumption.
>

Yes, this is legal. I'll see if I can clarify this in the text.

-Ekr

I think this scheme minimizes data sent over the wire (to reduce latency)
> and provides improved PFS vs using a non-encrypted session cache.  Since
> tickets are sent after encryption has been enabled, leaking the semi-static
> ticket encryption key does not enable an eavesdropper to decrypt past
> sessions, as was the case in TLS 1.2.  If the server is compromised, this
> scheme protects the session cache from being decrypted, so PFS is
> preserved, unlike the case with either TLS 1.2 session caches with no
> encryption or TLS 1.2 tickets with semi-static ticket keys.  Leaking either
> the session cache or ticket encryption key would allow prior TLS 1.2
> sessions to be decypted.
>
> Bill
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kyle Nekritz]

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.

Kyle

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Colm MacCárthaigh
Sent: Monday, March 14, 2016 2:29 PM
To: Subodh Iyengar <sub...@fb.com>
Cc: tls@ietf.org
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data



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

--
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Colm MacCárthaigh]

On Mon, Mar 14, 2016 at 1:47 PM, Ryan Hamilton  wrote:

> On Mon, Mar 14, 2016 at 12:25 PM, Salz, Rich  wrote:
>
>> > It's worth keeping in mind this recent paper about Replay attacks
>> against HTTPS. TL;DR: Attackers can already force a browser to replay
>> requests basically at will. ​As a result, it's not clear that 0-RTT replay
>> makes this situation worse.
>>
>> TLS is more than just browsers, which is what started this thread I think
>>
>
> I was responding to a comment about HTTP, though :> I agree that the
> implications of 0-RTT for other applications will be different.​
>

HTTP is much more than browsers;  there's a lot of non-browser APIs built
on top of it (aka web services and micro services). Across many vendors,
these APIs are commonly not replay safe; or they are safe within the
confines a small number of retries, but not a large unbounded number.

-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Geoffrey Keating]

Ryan Hamilton  writes:

> On Mon, Mar 14, 2016 at 12:12 PM, Geoffrey Keating 
> wrote:
> 
> > So, I don't think HTTP is generally safe against attacker-forced
> > replay, and would suggest great caution in allowing it.
> >
> 
> It's worth keeping in mind this recent paper about Replay attacks against
> HTTPS .
> TL;DR: Attackers can already force a browser to replay requests basically
> at will. ​As a result, it's not clear that 0-RTT replay makes this
> situation worse.

The blog indicates that it's possible to cause a browser to repeat a
request exactly once, within a short timeframe (probably 60 seconds or
so) before the browser times out; and the browser must not see the
first request succeed.  That's quite different from being able to let
a client make and complete a request, and then being to repeat that
request thousands of times over a period of hours or longer; even if
the client is a browser, it might be hard to convince it to do that.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

> It's worth keeping in mind this recent paper about Replay attacks against 
> HTTPS. TL;DR: Attackers can already force a browser to replay requests 
> basically at will. ​As a result, it's not clear that 0-RTT replay makes this 
> situation worse.

TLS is more than just browsers, which is what started this thread I think 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Colm MacCárthaigh]

On Mon, Mar 14, 2016 at 11:41 AM, Ilari Liusvaara 
wrote:
>
> (Also, with regards to my comment about cryptographic screwedness,
> such screwedness is not inherent in DH-0RTT, but is consequence of
> the current implementation).
>

This is interesting ... is there a way to do it that would preserve forward
secrecy?

-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Colm MacCárthaigh]

On Mon, Mar 14, 2016 at 11:27 AM, Subodh Iyengar  wrote:

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

Just on this; if you want to be sure of idempotency on the server side; the
best answer to is might be to intentionally send the data 2+ times at the
protocol level.  If the action really is idempotent, then the repeat will
be safe. Doing so as a matter of course builds up anti-bodies against any
nascent idempotency bugs.

Tackling it with new verbs and declarations is probably doomed to "I
thought it /was/ idempotent".

-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Colm MacCárthaigh]

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.

-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Subodh Iyengar]

> 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 [watsonbl...@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" 
<sub...@fb.com<mailto:sub...@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-boun...@ietf.org<mailto:tls-boun...@ietf.org>] on behalf of 
> Viktor Dukhovni [ietf-d...@dukhovni.org<mailto:ietf-d...@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.farr...@cs.tcd.ie<mailto:stephen.farr...@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 t

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

[Watson Ladd]

On Mar 14, 2016 11:04 AM, "Subodh Iyengar" <sub...@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-boun...@ietf.org] on behalf of Viktor Dukhovni [
ietf-d...@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.farr...@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=CwICAg=5VD0RTtNlTh3ycd41b3MUw=h3Ju9EBS7mHtwg-wAyN7fQ=WfBqzUVkz2aHPj_ZubNS486Z0f_mB52duCvuRK1GtSQ=qKrC1QXmZHVEq84oPhjuABuCzx4hwadP6c9TuTlMJx8=
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Subodh Iyengar]

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.

Subodh


From: TLS [tls-boun...@ietf.org] on behalf of Viktor Dukhovni 
[ietf-d...@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.farr...@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=CwICAg=5VD0RTtNlTh3ycd41b3MUw=h3Ju9EBS7mHtwg-wAyN7fQ=WfBqzUVkz2aHPj_ZubNS486Z0f_mB52duCvuRK1GtSQ=qKrC1QXmZHVEq84oPhjuABuCzx4hwadP6c9TuTlMJx8=

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Viktor Dukhovni]

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

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Colm MacCárthaigh]

On Sun, Mar 13, 2016 at 12:04 PM, Bill Cox  wrote:
>
> IMO, 0-RTT is the most important new feature in TLS 1.3 ...  Speed really
> _is_ that important.
>

I just want to be super explicit on this. There is a trade off to be made
here between fast and loose Vs security and safety. My take is that speed
absolutely is not so important that forward-secrecy for user requests, or
replay safety for applications should be compromised.

Even better speed benefits can be had by using persistent connections,
which incidentally are also a little more robust against traffic analysis.

-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Colm MacCárthaigh]

On Mon, Mar 14, 2016 at 4:32 AM, Eric Rescorla  wrote:

> For 1. Raw data throughput could be improved by envelope encrypting the
> early data; and transferring the envelope key only once the session has
> been fully authenticated
>

1. Client generates a random secret and uses it to derive encryption and
mac keys.
2. Client encrypts its early data using this key. Sends more-or-less per
0-RTT in the existing draft.
3. Post-handshake; the client sends a new message - encrypting using the
regular session key - which has the early data encryption and mac keys in
it.
4. Server uses those keys to decrypt the early data; which it buffered.
5. Client and server both erase and forget the ephemeral early data keys.

Useful if you want to upload a software update to Mars; maybe not to useful
to others; it just helps you make the most of the TCP window. So it
improves throughput, but not latency so much.

Can you expand on this. Cryptographically, this is effectively how both the
> DHE and PSK
> modes work: you get a key in session N (which is authenticated) and you
> use it
> in session N+1.
>


Makes sense!

-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Colm MacCárthaigh]

On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox  wrote:

> As we all know, what matters most in security is the default mode.  I am
> suggesting making the default 0-RTT resumption mode stateful, with a
> documented session-ID (and let's bring back the timestamp, too, since we'll
> need it).
>

Having state would make things much more robust; but rather than the state
being around the channel itself (the TLS session), would it be more robust,
and more flexible, for the state to be around the action? like some kind of
hint cookie.

One of the problems with session resumption is that in order to be replay
safe; the sequence number has to restart where it left off. That requires
some kind of transactional store, and if you're doing all of this for
latency, you may end up eating all of the wins there.

Another way to go would be a token that represents an action, e.g.:

1. As part of a regular TLS session, post handshake, client sends a
hint_request request layer message type. This can be URL, or any arbitrary
data, and it's encrypted just as normal application_data is.
2. Server responds with a hint_response token; it's just an opaque token.
3. For future TLS connections; client is free to include the hint token
data in the 0RTT handshake data.

Some interesting advantages:

1. The hint is very distinct from from the application_data stream.
2. The server can choose to use the token ticket-style; encrypt the URL or
whatever directly in the hint.
3. The server could also choose to use the token session-ID style; store it
in a lookup table.
4. Either way; the server has explicit control over what may constitute a
hint and it can be checked and locked down; before the client can transmit
something that may turn out not to be safe.
5. A server could also defer returning the token until the end of the
application session. Hints could be used as application layer resumption or
continuation tokens.

Some downsides:

1. Transactional safety is very difficult; idempotence at the application
layer is a very difficult to achieve property and this doesn't solve that.
2. Similar to TLS tickets/ids: the user's on-the-wire forward secrecy is at
the mercy of the server.
3. Hints could be used as super cookies for user-tracking.
4. Complicated request-response semantics post-handshake (similar to
Heartbeats).
5. Doesn't seem worth the complexity to me.

-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Bill Cox]

On Mon, Mar 14, 2016 at 4:39 AM, Eric Rescorla  wrote:

> This is just my opinion, not Google's.  Here is a dumb idea I just had:
>>
>> The current 0-RTT modes described in TLS 1.3 are clearly only for admins
>> who really know what they are doing.  If the current 0-RTT modes are deemed
>> to dangerous, then how about going back to session IDs, and doing 0-RTT
>> resumption from the session cache?
>>
>
> Isn't this more or less what we have been calling PSK-resumption? Can you
> explain
> the difference?
> -Ekr
>

Sometimes all you need is to rename a thing to make it acceptable to
everyone.  What should we call stateful 0-RTT resumption vs stateless 0-RTT
resumption to make the difference clear?  We have all been calling "0-RTT
resumption" the stateless version, whether DH-0RTT or PSK-resumption based
0-RTT.

Stateless PSK-resumption has all the "new and exciting" security holes.
Stateful PSK-resumption is boring, just like 1-RTT.  Stateless DH-0RTT and
PSK-resumption is well documented in the spec, but is dangerous.  Stateful
PSK-resumption is not documented in any way, and appears to have been
depreciated.  Users who want it will have to build it as a non-standard way
to use tickets, by encoding the session-ID in the ticket.  All I am
suggesting is to change the documentation so that the standard 0-RTT
resumption mode is the safe stateful version that puts the session-ID in
the ticket (and of course, drop the DH-0RTT mode).

As we all know, what matters most in security is the default mode.  I am
suggesting making the default 0-RTT resumption mode stateful, with a
documented session-ID (and let's bring back the timestamp, too, since we'll
need it).

Bill
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kyle Nekritz]

I think that idempotency is a relatively straightforward idea, it seems 
reasonable to trust that the application layer will only send 0-RTT data that 
is idempotent in terms of server-side state. I also don't think it's that much 
different than the current state of TLS. Providing strict replay protection 
over an unreliable network link requires that requests are never retried in the 
case of network failure - which is not practical in most applications. If the 
application doesn't already have some way to provide idempotency to requests 
that change state, it's likely already in a bad place (see 
http://blog.valverde.me/2015/12/07/bad-life-advice/).

However, to safely use 0-RTT (in the current draft), the 0-RTT data needs a 
stricter property than idempotency, it needs to be completely replay-safe. 
Unlike TLS now, where the opportunity for replay is linear in relation to the 
number of times a client is willing to retry a request, an attacker can replay 
a request an unlimited number of times.

There's two capabilities a passive eavesdropper gains from this that concern me 
the most:
1) Changes to the response's length and timing can be observed over time
2) The response's timing can be statistically analyzed (since the request 
can be replayed an unlimited number of times)
Mitigating these at the application layer seems much harder, if not impossible, 
to get right.

Adding a client time indicator (as I suggested in the other thread) makes this 
harder, but it certainly doesn't solve either problem. A server-side client 
nonce cache does solve these problems, which I think may be required to use 
0-RTT safely. That said, I echo Bill's comments about the need for 0-RTT in TLS 
1.3. Speed is very important.

Kyle

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Bill Cox
Sent: Sunday, March 13, 2016 6:23 PM
To: Scott Schmit <i.g...@comcast.net>
Cc: tls@ietf.org
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, Mar 13, 2016 at 2:23 PM, Scott Schmit 
<i.g...@comcast.net<mailto:i.g...@comcast.net>> wrote:

So why are we adding a protocol optimization known from the start to be
insecure (or less secure than you'd expect from using a PFS cipher
suite)?

If you require PFS with resolution on the order of seconds to minutes rather 
than hours to days, you probably do not want to use tickets either.  The ticket 
decryption key rotation schedule limits PFS.  0-RTT resumes do not make this 
worse.

What percentage of servers that have a perceived need for 0-RTT will be
able to securely use and benefit from this feature as their
infrastructure is actually implemented?

Well, Google already sees a significant fraction.  Going back to 1-RTT would be 
a significant downgrade.

If almost everyone should turn it off, why are we including it?

Almost every small site on the Internet should turn it off, but the large sites 
that want to enable it could make up a large fraction of all traffic.

Most server admins won't be reading the TLSv1.3 spec.  They're going to
see "shiny feature added specifically in this version that makes it
faster!" with *maybe* a warning that there are risks, which they'll
dismiss because "if it was so insecure, they wouldn't have included it
in the protocol in the first place."  Unless 0-RTT can be fixed, it
looks like an attractive nuisance.

I agree.  Instead of dropping 0-RTT, I think we should make it easy for admins 
to learn about what is involved in using 0-RTT in ways we believe are secure.  
The two modes I am aware of that are potentially as secure as TLS 1.2 session 
resumption are:

- Do 0-RTT session resumption using a session cache, using the ticket as the 
session ID.  This should have the same security as TLS 1.2 resume, right?
- At the HTTP app layer, make all requests that change state transaction based 
with unique transaction numbers, so replay attacks fail to change server state. 
 Done successfully, this should be more secure than TLS 1.2 resumption, 
shouldn't it?

Are we aware of other secure ways to do 0-RTT?

Bill
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nikos Mavrogiannopoulos]

On Sun, 2016-03-13 at 13:38 +0100, Eric Rescorla wrote:
> > 
> > However, if I'm in the rough about the above, (which seems
> > to me to be the case now) then my job as AD when I get a
> > publication
> > request that includes 0rtt, will include figuring out if that's
> > safe or not. And I've no clue how I'll do that unless the WG
> > have already done some analysis of the many, many protocols
> > that use TLS. Note that I do not consider "use a different API"
> > to be a sufficient answer here (it is necessary, but not
> > sufficient). 
> It seem to me that there are several important mitigating factors
> here.
> 
> 1. Nothing requires applications to use this feature at all. First,
> servers
> need to advertise it and are free to (a) not offer clients the
> ability to send
> 0-RTT data and (b) refuse to accept it if clients send it. Moreover,
> everyone
> I know of who is considering building a 1.3 library intends to
> provide
> that data to the server via a separate API, so the server will have
> to work
> to get it.

It is important to see how protocols are perceived. For many people TLS
1.3 with 0rtt will be the same as TLS 1.3. The first publication of an
attack against TLS 1.3 with rtt, will be perceived as an attack against
TLS 1.3 protocol. Even if the published attack against TLS 1.3 with
0rtt was an expected one (i.e., replay of data), if the attack impact
is high, that may not be sufficient to stop the avalanche of bad
publicity. In turn that will lead several people losing confidence to
TLS 1.3 as a protocol, even TLS and the IETF process overall.
 
My suggestion, if you need 0rtt, publish it as a different document,
don't mix it with TLS 1.3. The security requirements from TLS are
vastly different from the security requirements of a 0rtt protocol.

regards,
Nikos

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

On Sun, Mar 13, 2016 at 8:51 PM, Colm MacCárthaigh 
wrote:

> On Sun, Mar 13, 2016 at 4:14 AM, Stephen Farrell <
> stephen.farr...@cs.tcd.ie> wrote:
>
>> With 0rtt, I think it also becomes a dangerous
>> implement. So, that's my personal opinion, while not wearing an
>> AD hat.
>>
>
> +1 for this as 0RTT is outlined in the draft. But to expand a little:
>
> * Losing forward secrecy for "GET" requests and user cookies seems like a
> very bad privacy trade-off. Collection of wire data, combined with a bug or
> an attack that could disclose the ECDH parameters, does not seem so far
> fetched these days.
>
> * I imagine that 0RTT data may be intended for pre-fetching hints, e.g.
> "I'm request URL foo as user bar, so please get a start on fetching the
> resources I need". That suggests trivial application-level "is the cache
> warm" side channels, or "lets trash the whole cache" DOS attacks, would
> both be common.
>
> * A vast number of APIs build on top of TLS/HTTPS are not idempotent or
> replay safe. Even carefully designed APIs may have subtle side effects such
> as a user being charged for the request, or the request counting towards a
> throttle of some kind. Even ones as silly as there go your 10 free nytimes
> articles; or booting an opponent out of your less-than-friendly sudoku
> tournament.
>
> * The draft calls out that early data needs to be handled differently than
> regular TLS data. This reminds me of the problems with renegotiatable
> client authentication - similar to what Marsh Ray highlighted a long time
> ago. What if a request or action spans both the early and the regular data
> sections? what would a "safe" API look like, for an SSL/TLS library layer?
>
> It seems like the benefits of of 0-RTT boil down to two things;
>
> 1. Increased throughput
> 2. Give the recipient a chance to a get a head-start on servicing some
> kind of request.
>
> For 1. Raw data throughput could be improved by envelope encrypting the
> early data; and transferring the envelope key only once the session has
> been fully authenticated
>

Can you expand on this. Cryptographically, this is effectively how both the
DHE and PSK
modes work: you get a key in session N (which is authenticated) and you use
it
in session N+1.


-Ekr

. Not that interesting to most people; but works. I can't think of a good
> way to achieve 2 without all of the problems that have been mentioned.
>
> At a minimum I'd suggest that the draft could not call it "data", but
> maybe instead "hint"; and make it so that early_data and application_data
> are not supposed to appear sequentially in a stream. E.g. someone calling
> TLSRead() or whatever should never expect to see the early_data; it's a
> deliberate and separate stream.
>



> --
> Colm
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Sun, Mar 13, 2016 at 09:26:14PM -0400, Harlan Lieberman-Berg wrote:
> 
> I agree with a slight tweak in wording here, Bill.  I think that we
> /should/ drop the parts of 0-RTT where we are not confident that an
> admin who blindly enables functionality in TLS 1.3 will not end up
> harming themselves.
> 
> More generally, I strongly believe that TLS 1.3 should not
> provide options which we think should be restricted to "admins who know
> what they're doing".  These end up hurting us down the line (cf EXPORT
> cipher suites.)
> 
> I think we should ship the parts of 0-RTT that we believe are
> intrinsically safe for (the vast majority) of the internet to enable and
> use on day 1.

Here are what I think would be reasonable restrictions on 0-RTT:
- Require labeling the application protocol 0RTT data is for.
  * To prevent cross-protocol attacks.
- Require application protocol to profile the semantics of 0RTT data.
  * To at least get some idea of protocol-level security properties.
  * Some applications might need to handle 0RTT specially for
security reasons (HTTP/2?)
- Require application to specifically request 0RTT data.
  * To prevent unaware applications from thinking it has the same
properties as main data.
- Require 0RTT data to be kept separate from main application data.
  * To make more difficult for applications to mix it up.
- Ensure that no 0RTT mode invokes screwy cryptographic behaviour.
  * Famous last words: "Not believed to be exploitable".


And none of these should be subject to "admin configuration"
(disabling entiere 0-RTT is).


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Colm MacCárthaigh]

Ar Dé Domhnaigh 13 Márta 2016, scríobh Eric Rescorla :
>
>
> 1. Nothing requires applications to use this feature at all. First, servers
> need to advertise it and are free to (a) not offer clients the ability to
> send
> 0-RTT data and (b) refuse to accept it if clients send it. Moreover,
> everyone
> I know of who is considering building a 1.3 library intends to provide
> that data to the server via a separate API, so the server will have to work
> to get it.
>

security is very difficult to judge and measure - but speed is very easy.
This sets up a sort of "race to the bottom" where providers may feel
pressured to respond and enable an unsafe feature; because the speed
benefit is more apparent than the loss of security.  There's a real trade
off; we should favor the s in tls :)

-
Colm


-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Colm MacCárthaigh]

On Sun, Mar 13, 2016 at 4:14 AM, Stephen Farrell 
wrote:

> With 0rtt, I think it also becomes a dangerous
> implement. So, that's my personal opinion, while not wearing an
> AD hat.
>

+1 for this as 0RTT is outlined in the draft. But to expand a little:

* Losing forward secrecy for "GET" requests and user cookies seems like a
very bad privacy trade-off. Collection of wire data, combined with a bug or
an attack that could disclose the ECDH parameters, does not seem so far
fetched these days.

* I imagine that 0RTT data may be intended for pre-fetching hints, e.g.
"I'm request URL foo as user bar, so please get a start on fetching the
resources I need". That suggests trivial application-level "is the cache
warm" side channels, or "lets trash the whole cache" DOS attacks, would
both be common.

* A vast number of APIs build on top of TLS/HTTPS are not idempotent or
replay safe. Even carefully designed APIs may have subtle side effects such
as a user being charged for the request, or the request counting towards a
throttle of some kind. Even ones as silly as there go your 10 free nytimes
articles; or booting an opponent out of your less-than-friendly sudoku
tournament.

* The draft calls out that early data needs to be handled differently than
regular TLS data. This reminds me of the problems with renegotiatable
client authentication - similar to what Marsh Ray highlighted a long time
ago. What if a request or action spans both the early and the regular data
sections? what would a "safe" API look like, for an SSL/TLS library layer?

It seems like the benefits of of 0-RTT boil down to two things;

1. Increased throughput
2. Give the recipient a chance to a get a head-start on servicing some kind
of request.

For 1. Raw data throughput could be improved by envelope encrypting the
early data; and transferring the envelope key only once the session has
been fully authenticated. Not that interesting to most people; but works. I
can't think of a good way to achieve 2 without all of the problems that
have been mentioned.

At a minimum I'd suggest that the draft could not call it "data", but maybe
instead "hint"; and make it so that early_data and application_data are not
supposed to appear sequentially in a stream. E.g. someone calling TLSRead()
or whatever should never expect to see the early_data; it's a deliberate
and separate stream.

-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Harlan Lieberman-Berg]

Bill Cox  writes:
>> Most server admins won't be reading the TLSv1.3 spec.  They're going to
>> see "shiny feature added specifically in this version that makes it
>> faster!" with *maybe* a warning that there are risks, which they'll
>> dismiss because "if it was so insecure, they wouldn't have included it
>> in the protocol in the first place."  Unless 0-RTT can be fixed, it
>> looks like an attractive nuisance.
>
> I agree.  Instead of dropping 0-RTT, I think we should make it easy for
> admins to learn about what is involved in using 0-RTT in ways we believe
> are secure.  [snip]

I agree with a slight tweak in wording here, Bill.  I think that we
/should/ drop the parts of 0-RTT where we are not confident that an
admin who blindly enables functionality in TLS 1.3 will not end up
harming themselves.

More generally, I strongly believe that TLS 1.3 should not
provide options which we think should be restricted to "admins who know
what they're doing".  These end up hurting us down the line (cf EXPORT
cipher suites.)

I think we should ship the parts of 0-RTT that we believe are
intrinsically safe for (the vast majority) of the internet to enable and
use on day 1.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Erik Nygren]

On Sun, Mar 13, 2016 at 12:21 PM, Eric Rescorla  wrote:

>
> On Sun, Mar 13, 2016 at 3:51 PM, Yoav Nir  wrote:
>
>>
>> > On 13 Mar 2016, at 4:45 PM, Salz, Rich  wrote:
>> >
>> >> I also think it is prudent to assume that implementers will turn on
>> replayable
>> >> data even if nobody has figured out the consequences.
>> >
>> > I very much agree.  Customers, particularly those in the mobile field,
>> will look at this and say "I can avoid an extra RTT?  *TURN IT ON*" without
>> fully understanding, or perhaps even really caring about, the security
>> implications.
>>
>> Perhaps, and I think IoT devices are likely to do so as well.
>>
>> Is OpenSSL going to implement this? Are all the browsers?
>>
>
> There are already patches in preparation for this for NSS and I expect
> Firefox to
> implement it, as long as we have any indication that a reasonable numbers
> of
> servers will accept it.
>

I share some of the concerns expressed in this thread that 0RTT has the
risk of becoming an attractive nuisance.  Once browsers start supporting
it, server operators will feel competitive pressure to support it.  And
this will then put additional pressure onto more browsers to support it,
possibly pushing the edges where it is safe.

For example, when is HTTP GET safe vs not safe and who makes this call?
Especially if you have a browser that assumes that GET should be idempotent
and can be sent via 0RTT early data, a web developer whose never heard of
the word "idempotent" and builds an app with GET with side-effects but
assumes its safe since it's over TLS, and a server operator who is just
turning on a vendor provided feature which their users requested, not to
mention perhaps having a CDN or load-balancing-tls-terminating-proxy that
doesn't have a good way to convey the risks across two connections.  One
idea for HTTP that I'm increasingly in-favor of might be to define a new
method ("GET0"?)  and require that browsers use one of these new methods in
the early data request to expose this as high in the stack as possible.

It seems like there is a level of diminishing returns here if we compare
some of the options (not meant to be strictly ordered below):

1) We have old-school cleartext over TCP which has 1RTT before client data
(due to SYN/SYNACK)
2) We have TCP + TLS 1.[012] which has both the SYN/SYNACK plus the 2RTT
behavior means 3RTT before client data.
3) We have TCP TFO + TLS 1.3 1RTT which yields 1RTT before client data  (or
back to the same as #1 for resumption)
4) We have TCP (no TFO) + TLS 1.3 0RTT which also yields 1RTT before client
data for resumption
5) Then there's TCP TFO + TLS 1.3 0RTT which yields 0RTT before client data
for resumption
6) And finally there's old-school cleartext TCP TFO which has 0RTT before
client data, but which people are very hesitant to use for HTTP due to
replay issues.

Of these, #3 and #4 yield similar performance (with some limitations around
#3, such as requiring the same server IP or server IP prefix in some newer
drafts).

>From this, a few thoughts jump to mind from this:

* We get many of the same benefits 0RTT with using TCP TFO (TCP FastOpen)
and TLS 1.3 1RTT mode together as we get when using TLS 1.3 0RTT and stock
TCP.  TFO seems much safer here since its replay risks are at a lower level
that should be safe for TLS outside of the 0RTT context.  Note that there
are some issues with middleboxes sometimes breaking badly (blocking all
connections from a client IP for 30 seconds) when it tries to use TFO as
discussed recently in TCPM, but we may all want to focus some effort on
getting those fixed.
* We'll almost certainly want to make sure that any UDP-based protocol
(DTLS 1.3 or QUIC-over-TLS-1.3) can do a true 1RTT handshake safely in a
common case.  (ie, in a way that mirrors TCP TFO + TLS 1.3 1RTT.)  I
suspect this will be the bare minimum for getting QUIC to switch to use TLS
1.3.
* It seems like the risks around TLS 1.3 0RTT and TFO are similar (with TCP
being a protocol not trying to provide security properties).  If people
have been very wary to enable TFO for cleartext HTTP due to risks from
duplicated packets, shouldn't we be even more worried about TLS 1.3 0RTT
since the next-layer-up semantic issues and risks are similar, but TLS 1.3
0RTT potentially even has fewer mitigators?  (eg, we don't bind the server
IP in cryptographically to the request the client is making --- although
that might be an interesting addition to help make TLS 1.3 0RTT safer?)


There may also be some hacks that make TLS 1.3 0RTT marginally safer,
although I'm sure there are situations where they don't work and they may
just provide a false sense of security:
* Have the client include a time-delta-relative-to-PSK-issuance, as Martin
suggested.  (To allow the server to bound the duration of replay attacks.)
* Include the server IP in the client_hello for 0RTT  (to prevent replays
against different clusters).  There are a bunch 

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

[Scott Schmit]

On Sun, Mar 13, 2016 at 11:14:13AM +, Stephen Farrell wrote:
> First, with no hats, if the WG were to have a poll on whether
> or not to include 0rtt in TLS1.3, then as a participant in the
> work here, I'd be firmly arguing to leave it out entirely. I
> really think an over-emphasis on reducing latency for browsers
> is going to bite us (and the Internet) in the ass in the same
> ways that emphasising interop over security has in the past with
> fallbacks to older, worse versions of TLS/SSL, with all their
> inherent flaws and bits of e.g. crappy "export" crypto support.
> Absent 0rtt, TLS1.3 seems to me to be an excellent step forward
> in security. With 0rtt, I think it also becomes a dangerous
> implement. So, that's my personal opinion, while not wearing an
> AD hat.

I think you're exactly right.  Let's look at the vulnerabilities in TLS:
- Renegotiation attack
  - Optimization to establish a new TLS session without reestablishing a
TCP/IP connection.  Broken repeatedly despite analysis, etc.
  - TLSv1.3's answer?  Drop renegotiation.
- BEAST
  - CBC chained off the last block sent so that an explicit IV need not
be sent on the wire.  Another optimization.
  - TLSv1.3's answer?  Drop CBC.
- CRIME / BREACH
  - Compression was supported to speed up connections (less data to
process/transfer).  Optimization, again.
  - TLSv1.3's answer?  Drop compression.
- Lucky Thirteen / Padding timing attacks / POODLE
  - Years later, servers are still vulnerable because insecure
algorithms & versions remain enabled, even with the publicity around
POODLE
  - TLSv1.3's answer?  Drop the bad cipher suites and offering < 1.0.
- RC4
  - RC4 is known to be weak, but it continues to be widely used
  - SSL/TLS included it because analysis said it was secure as used.
  - TLSv1.3's answer?  Drop RC4.
- FREAK / Logjam (downgrade attacks)
  - This happened because TLS vendors left obsolete export algorithms
implemented, and server admins left them enabled.
  - TLSv1.3's answer?  Drop the insecure cipher suites.
- DROWN
  - Why is this even an issue?  Because people STILL haven't turned off
SSLv2 *twenty* *years* after it was known to be insecure!!
  - TLSv1.3's answer?  Drop compatibility with SSLv2.

So why are we adding a protocol optimization known from the start to be
insecure (or less secure than you'd expect from using a PFS cipher
suite)?

What percentage of servers that have a perceived need for 0-RTT will be
able to securely use and benefit from this feature as their
infrastructure is actually implemented?

If almost everyone should turn it off, why are we including it?

Most server admins won't be reading the TLSv1.3 spec.  They're going to
see "shiny feature added specifically in this version that makes it
faster!" with *maybe* a warning that there are risks, which they'll
dismiss because "if it was so insecure, they wouldn't have included it
in the protocol in the first place."  Unless 0-RTT can be fixed, it
looks like an attractive nuisance.

Let's leave it out.

-- 
Scott Schmit


smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

On Sun, Mar 13, 2016 at 11:14:13AM +, Stephen Farrell wrote:
> 
> I've been worried about this for a while now, but the recant
> thread started by Kyle Nekritz [3] prompted me to send this
> as I think that's likely just the tip of an iceberg. E.g., I'd
> be worried about cross-protocol attacks one might be able to
> try with JS in a browser if the JS can create arbitrary HTTP
> header fields which I think is the case. I'm also worried about
> things like EAP-TLS and RADIUS/Diameter if used via TLS etc
> where we don't necessarily have the right people active on this
> list. While I don't have any concrete attacks, the ability to
> create replayable data smells really really bad to me and I've
> no idea how we can honestly be confident we've done a good job
> on TLS1.3 while such smells linger.

Also, it occurs to me that problems can arise if one tries to
combine 0-RTT data with ALPN. The 0-RTT datablock is probably
only appropriate for one of the protocols...

If it is HTTP/2 vs. HTTP/1.1, if you get it wrong, the connection
will break (the HTTP/2 prelude). Wonder if one is so fortunate with
some other protocol pairs...

Hmm... That got me some ideas...

> I'd also note that my overall impression of the TRON w/s was that
> researchers thought 1rtt was mostly ready, but that there was
> no similar confidence in 0rtt. I also don't think "another TRON" is
> the answer here, as we'd not have the right people in the room
> who'd know the consequences of replay for all instances of /TLS.

TLS 1.3 1-RTT is just boring, unless you are trying to do something
at least a bit screwy, like mix pure-PSK and client-auth.
 
No such luck with 0-RTT. There is all sorts of cryptographic screwyness
in there too (through getting rid of DH-0RTT should eliminate that).


Also, it occurs to me that very few protocols are even nearly as
vulernable to these kind of issues than HTTP, including cases where
one end is speaking HTTP but the other is not...



-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

> Personally, I think we should start without 0 RTT until we have a better
> understanding of what the consequences are.

For those who don't know, Kurt is on the openssl-dev team (longer than me), but 
is just more quiet and modest about it :)

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

On Sun, Mar 13, 2016 at 3:51 PM, Yoav Nir  wrote:

>
> > On 13 Mar 2016, at 4:45 PM, Salz, Rich  wrote:
> >
> >> I also think it is prudent to assume that implementers will turn on
> replayable
> >> data even if nobody has figured out the consequences.
> >
> > I very much agree.  Customers, particularly those in the mobile field,
> will look at this and say "I can avoid an extra RTT?  *TURN IT ON*" without
> fully understanding, or perhaps even really caring about, the security
> implications.
>
> Perhaps, and I think IoT devices are likely to do so as well.
>
> Is OpenSSL going to implement this? Are all the browsers?
>

There are already patches in preparation for this for NSS and I expect
Firefox to
implement it, as long as we have any indication that a reasonable numbers of
servers will accept it.

-Ekr


> (only the first one is directed specifically at you, Rich…)
>
> Yoav
>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Kurt Roeckx]

On Sun, Mar 13, 2016 at 04:51:49PM +0200, Yoav Nir wrote:
> 
> Is OpenSSL going to implement this?

Personally, I think we should start without 0 RTT until we have a
better understanding of what the consequences are.


Kurt

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

> Is OpenSSL going to implement this? Are all the browsers?
> 
> (only the first one is directed specifically at you, Rich…)

I can answer the second question more easily :)  Yes the browsers will.

OpenSSL is unlikely to have TLS 1.3 before end of 2016 and I don't know what 
we'll do.  Right now we're finishing up our major 1.1 release, due in a month 
or so.  And then we'll figure out our 1.3 story.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

On 13/03/16 14:49, Eric Rescorla wrote:
>  Perhaps we could start by actually sponsoring some of those
> reviews. Given that HTTP is the primary customer for 0-RTT, perhaps
> Mark or Martin would be willing to start a review there?

I think that'd really help esp. if we can get folks looking at a
range of protocols that use TLS.

For the web, I'm pretty confident that the analysis will be done
and done well - that is the main use-case motivating this after
all. But getting that started now would still be great.

Getting a few non-web cases analysed would be great too if we
can figure a way to help get that to happen.

Cheers,
S.



smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 13 Mar 2016, at 4:45 PM, Salz, Rich  wrote:
> 
>> I also think it is prudent to assume that implementers will turn on 
>> replayable
>> data even if nobody has figured out the consequences.
> 
> I very much agree.  Customers, particularly those in the mobile field, will 
> look at this and say "I can avoid an extra RTT?  *TURN IT ON*" without fully 
> understanding, or perhaps even really caring about, the security 
> implications. 

Perhaps, and I think IoT devices are likely to do so as well.

Is OpenSSL going to implement this? Are all the browsers?

(only the first one is directed specifically at you, Rich…)

Yoav



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

On Sun, Mar 13, 2016 at 3:41 PM, Stephen Farrell 
wrote:

>
> Hiya,
>
> On 13/03/16 14:01, Eric Rescorla wrote:
> >
> > This is not an accurate way to represent the situation. Those WGs can
> safely
> > move from TLS 1.2 to 1.3 *as long as they don't use 0-RTT*.
>
> I agree your 2nd sentence but not your 1st.
>
> I also think it is prudent to assume that implementers will turn on
> replayable data even if nobody has figured out the consequences.


That may well be true, but I don't believe that it allows us to make
progress.
We already know that there are conditions in which 0-RTT is unsafe. That's
why
the specification has extensive caveats around its use. Therefore, either we
(collectively) can:

- Not specify it at all.
- Specify it and provide warnings that people should only use it in certain
  circumstances and attempt to delineate these circumstances.

In my original message, I proposed that we restrict the use of 0-RTT to
settings where it has been explicitly profiled. Your response seems to be
that people will turn it on even if we do so. But if that's your position
then
there's no point in doing any analysis because we already know that there
are cases where it's not safe, which is why we are warning them against
using it in those cases.

In any case, I'm a little surprised by your assertion in a previous message
that WGs expect us to do this analysis. That's not been the relationship
we've have with WGs in the past; rather, we document the properties we
are providing and they have to determine whether those properties are
appropriate. Perhaps we could start by actually sponsoring some of those
reviews. Given that HTTP is the primary customer for 0-RTT, perhaps
Mark or Martin would be willing to start a review there?

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

>  I also think it is prudent to assume that implementers will turn on 
> replayable
> data even if nobody has figured out the consequences.

I very much agree.  Customers, particularly those in the mobile field, will 
look at this and say "I can avoid an extra RTT?  *TURN IT ON*" without fully 
understanding, or perhaps even really caring about, the security implications. 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

Hiya,

On 13/03/16 14:01, Eric Rescorla wrote:
> 
> This is not an accurate way to represent the situation. Those WGs can safely
> move from TLS 1.2 to 1.3 *as long as they don't use 0-RTT*.

I agree your 2nd sentence but not your 1st.

I also think it is prudent to assume that implementers will turn on
replayable data even if nobody has figured out the consequences.

Cheers,
S.



smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

On Sun, Mar 13, 2016 at 2:51 PM, Stephen Farrell 
wrote:
>
> > That allows
> > the
> > experts in those protocols to do their own analysis, rather than somehow
> > making it the responsibility of the TLS WG. I agree that this is a sharp
> > object
> > and I'd certainly be happy to have such a requirement in 1.3.
>
> So again, I totally understand the reluctance to consider all of the
> foo/TLS options within the TLS WG. And I don't even know how one
> might get that done if one wanted. (Hence my asking the WG.)
>
> However, it is the TLS WG that is introducing the dangerous implement
> and as part of a protocol revision that is mainly intended to improve
> security. It seems fair to say that that may be a surprise for folks
> who just want to use TLS.
>
> My guess would be that if we say to all the WG's doing foo/TLS that
> they need to write a new document before they safely can move from
> TLS1.2 to TLS1.3,


This is not an accurate way to represent the situation. Those WGs can safely
move from TLS 1.2 to 1.3 *as long as they don't use 0-RTT*.

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

Hiya,

I mostly agree with what you wrote about specific mitigating factors
for specific potential threats.

For this thread though, maybe we're better talking about how we might
get to where we can be confident that replayable data in TLS1.3 won't
cause significant harm. I'm happy to talk more about the specifics as
well but maybe better to try figure out what are a good set of goals
first (or in parallel).

I think this bit maybe captures where you and I might most come from
different perspectives:

On 13/03/16 12:38, Eric Rescorla wrote:
> 
> Yes, this might be the case, though as above, I note that nothing is making
> those protocols use this feature, 

Sure. Except we *know* that people will see a new API and will use
that to go faster, even if they ought not. TBH, I really don't think
the API approach is sufficient by itself.

> and the specification is quite clear about
> the risks involved here. Rather than requiring some open-ended exploration

"requiring open-ended" doesn't match what I'm asking for. I can
understand your concern though.

I'm trying to figure out how we (the IETF) get to where we are
confident that we understand the important impacts of introducing this
dangerous implement. As I said, I am puzzled as to how we get there and
am asking that the WG help figuring that out before we get to when
tackling issues we find gets harder.

> of the impact on every protocol of this feature, I think it would be far
> more
> sensible to require that protocols not use 0-RTT absent some specific
> application layer profile describing when and why it is safe. 

I think some such statement would help for sure. I'm not sure though if
it's really sufficient. Even if 0rtt was to be in a separate RFC (I
forget if the WG considered that) the issue is that libraries will all
include it (as it'll make the web go faster) so implementers are liable
to turn it on anywhere really.

> That allows
> the
> experts in those protocols to do their own analysis, rather than somehow
> making it the responsibility of the TLS WG. I agree that this is a sharp
> object
> and I'd certainly be happy to have such a requirement in 1.3.

So again, I totally understand the reluctance to consider all of the
foo/TLS options within the TLS WG. And I don't even know how one
might get that done if one wanted. (Hence my asking the WG.)

However, it is the TLS WG that is introducing the dangerous implement
and as part of a protocol revision that is mainly intended to improve
security. It seems fair to say that that may be a surprise for folks
who just want to use TLS.

My guess would be that if we say to all the WG's doing foo/TLS that
they need to write a new document before they safely can move from
TLS1.2 to TLS1.3, they'll answer back that the TLS WG should have done
some or all of that before introducing the dangerous implement.

There are at least two bad approaches here I think. One is "higher
layers need to do all the work to figure out if moving from TLS1.2 to
TLS1.3 is safe." Another is "the TLS WG needs to figure out and say if
foo/TLS1.3 is safe for all ."

My issue is that I don't know what middle-ground here is reasonable
and gives us sufficient confidence that TLS1.3 with the dangerous
implement is safe enough.

Cheers,
S.



smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

On Sun, Mar 13, 2016 at 12:14 PM, Stephen Farrell  wrote:
>
>
> However, if I'm in the rough about the above, (which seems
> to me to be the case now) then my job as AD when I get a publication
> request that includes 0rtt, will include figuring out if that's
> safe or not. And I've no clue how I'll do that unless the WG
> have already done some analysis of the many, many protocols
> that use TLS. Note that I do not consider "use a different API"
> to be a sufficient answer here (it is necessary, but not
> sufficient).


It seem to me that there are several important mitigating factors here.

1. Nothing requires applications to use this feature at all. First, servers
need to advertise it and are free to (a) not offer clients the ability to
send
0-RTT data and (b) refuse to accept it if clients send it. Moreover,
everyone
I know of who is considering building a 1.3 library intends to provide
that data to the server via a separate API, so the server will have to work
to get it.

2. The replay issues are mostly problematic in cases that trouble
maintaining consistent state (primarily distributed machines).
Non-distributed
systems can maintain a replay cache and refuse to accept traffic which
appears to be a replay. This does not reduce the risk to zero but it
significantly
reduces it to state loss issues, which are easier to control for. So it
would
probably be useful to document some anti-replay mechanism based on the
ClientHello fo such protocols.


I've been worried about this for a while now, but the recant
> thread started by Kyle Nekritz [3] prompted me to send this
> as I think that's likely just the tip of an iceberg. E.g., I'd
> be worried about cross-protocol attacks one might be able to
> try with JS in a browser if the JS can create arbitrary HTTP
> header fields which I think is the case.


It's not generally the case without server consent. CORS prohibits the use
of any
non-simple headers in CORS requests without preflight. See:

https://fetch.spec.whatwg.org/#concept-main-fetch
and
https://fetch.spec.whatwg.org/#simple-header




> I'm also worried about
> things like EAP-TLS and RADIUS/Diameter if used via TLS etc
> where we don't necessarily have the right people active on this
> list.


Yes, this might be the case, though as above, I note that nothing is making
those protocols use this feature, and the specification is quite clear about
the risks involved here. Rather than requiring some open-ended exploration
of the impact on every protocol of this feature, I think it would be far
more
sensible to require that protocols not use 0-RTT absent some specific
application layer profile describing when and why it is safe. That allows
the
experts in those protocols to do their own analysis, rather than somehow
making it the responsibility of the TLS WG. I agree that this is a sharp
object
and I'd certainly be happy to have such a requirement in 1.3.

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls