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

From: Stephen Farrell <[email-masked]>
Date: Sun, 13 Mar 2016 11:14:13 +0000

Hiya,

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.

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). Given that there are 263 RFCs that reference RFC5246 [1]
and google scholar counts 2738 documents that cite RFC5246 [2] I'm
puzzled as to how we can know the consequences of adding that
dangerous implement to TLS1.3.

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.

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 <foo>/TLS.

Lastly, just in case: Note that I am not saying that I'll block
a publication request for TLS1.3 that includes 0rtt based on
my own technical opinion if I'm in the rough. I'm saying that I
have no idea how I'll do an AD evaluation of such a thing so
I need help from the WG in analysing the broader impact of 0rtt,
and if that's not done before the publication request, we'll have
to figure it out then. And that could be messy, if we make a
bunch of late discoveries that 0rtt creates issues for a bunch of
instances of <foo>/TLS1.3.

So, can people suggest ways in which we can figure out the impact
of replayable data across all the many uses of TLS?

Thanks,
S.

[1] http://www.arkko.com/tools/allstats/citations-rfc5246.html
[2]
https://scholar.google.com/scholar?q=http%3A%2F%2Fwww.hjp.at%2Fdoc%2Frfc%2Frfc5246.html&btnG=&hl=en&as_sdt=0%2C5
[3] https://mailarchive.ietf.org/arch/msg/tls/K-PmKrP6Df_qIVq_BTielgtQwUY

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 13 Mar 2016 13:38:03 +0100

On Sun, Mar 13, 2016 at 12:14 PM, Stephen Farrell <[email-masked]
> wrote:
> 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.

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

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 13 Mar 2016 13:51:40 +0000

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

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

> 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

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

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.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 13 Mar 2016 15:01:56 +0100

On Sun, Mar 13, 2016 at 2:51 PM, Stephen Farrell <[email-masked]>
wrote:
> 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

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 13 Mar 2016 14:41:15 +0000

Hiya,

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

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 13 Mar 2016 14:45:19 +0000

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

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 13 Mar 2016 15:49:45 +0100

> 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

---

From: Yoav Nir <[email-masked]>
Date: Sun, 13 Mar 2016 16:51:49 +0200

> On 13 Mar 2016, at 4:45 PM, Salz, Rich <[email-masked]> wrote:
> 

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

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 13 Mar 2016 14:54:23 +0000

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

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 13 Mar 2016 14:54:55 +0000

On 13/03/16 14:49, Eric Rescorla wrote:
>  Perhaps we could start by actually sponsoring some of those

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.

---

From: Kurt Roeckx <[email-masked]>
Date: Sun, 13 Mar 2016 17:12:57 +0100

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

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 13 Mar 2016 17:21:28 +0100

On Sun, Mar 13, 2016 at 3:51 PM, Yoav Nir <[email-masked]> wrote:

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

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

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 13 Mar 2016 16:45:39 +0000

> 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 :)

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 13 Mar 2016 20:23:36 +0200

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

> who'd know the consequences of replay for all instances of <foo>/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

---

From: Andrei Popov <[email-masked]>
Date: Sun, 13 Mar 2016 19:04:13 +0000

What Stephen said about 0-RTT makes a lot of sense to me. However, if one major browser implements this latency reduction feature, the rest will feel compelled to do the same. And EKR’s message below indicates that at least one major browser will support 0-RTT.

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Sunday, March 13, 2016 9:21 AM
To: Yoav Nir <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, Mar 13, 2016 at 3:51 PM, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:

> On 13 Mar 2016, at 4:45 PM, Salz, Rich <[email-masked]<mailto:[email-masked]>> wrote:
>

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

Yoav

---

From: Bill Cox <[email-masked]>
Date: Sun, 13 Mar 2016 12:04:43 -0700

> in there too (through getting rid of DH-0RTT should eliminate that).

This is just my personal opinion:

I second your opinion that as Ekr suggested, TLS 1.3 should drop DH-0RTT.
Only 0-RTT resume should be supported.  That way, we start off with the
same security as 1-RTT, simplifying analysis and reducing vulnerabilities.

IMO, 0-RTT is the most important new feature in TLS 1.3, though the current
spec giving us two different ways to shoot ourselves in the foot with 0-RTT
seems redundant.  While this is in no way related to my job within Google,
I do not see how a company like Google could justify switching from QUIC
crypto to TLS 1.3 without a 0-RTT capability.  Note that the job I actually
do at Google, working on Token Binding, is significantly threatened by
0-RTT (just like client-certs), so I have plenty of reason to be against
0-RTT.  I just feel the world needs 0-RTT.  Speed really _is_ that
important.

Finally, I feel that while the TLS 1.3 spec does a good job of trying to
scare away people from 0-RTT, it would be better if we also explained what
is required to use 0-RTT in a secure mode.  Perhaps this does not belong in
the spec, but at least a link to read about it should be, IMO.  It _can_ be
done, if the client and server are willing to pay the high cost required.

Bill

---

From: Scott Schmit <[email-masked]>
Date: Sun, 13 Mar 2016 17:23:42 -0400

> implement. So, that's my personal opinion, while not wearing an

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

---

From: Bill Cox <[email-masked]>
Date: Sun, 13 Mar 2016 15:22:47 -0700

> insecure (or less secure than you'd expect from using a PFS cipher

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.

> infrastructure is actually implemented?

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

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.

> 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

---

From: Erik Nygren <[email-masked]>
Date: Sun, 13 Mar 2016 18:33:21 -0400

> implement it, as long as we have any indication that a reasonable numbers

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 of NAT-style scenarios
where this breaks, but it might help in a few places.  This also doesn't
help for server clusters using anycast.
* The anti-replay nonce (which helps in some places, but isn't possible to
implement sanely in many other scenarios).

At a minimum, I agree with the suggestion that we should require underlying
protocols to specify where and how it is safe to use.  (Although which of
the browsers discussing implementing is willing to wait for this draft for
HTTP to be mature enough?  I'm actually quite curious here.)

         Erik

[All opinions expressed here are my own.]

---

From: Harlan Lieberman-Berg <[email-masked]>
Date: Sun, 13 Mar 2016 21:26:14 -0400

Bill Cox <[email-masked]> writes:
> 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

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sun, 13 Mar 2016 20:51:57 -0700

On Sun, Mar 13, 2016 at 4:14 AM, Stephen Farrell <[email-masked]>
wrote:

> With 0rtt, I think it also becomes a dangerous

+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

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sun, 13 Mar 2016 21:15:37 -0700

> that data to the server via a separate API, so the server will have to work

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

---

From: Bill Cox <[email-masked]>
Date: Sun, 13 Mar 2016 21:29:13 -0700

> intrinsically safe for (the vast majority) of the internet to enable and

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?

This is not only fairly simple given the existing code base, but it fits
well with my personal bias towards supporting strong client authentication,
which basically got thrown under the bus in the current 0-RTT scheme.
Frankly, my current job (working on token binding) is a lot less appealing
in a world where servers cannot do proofs-of-possession with clients.  With
0-RTT cached session resumption, the TLS sequence numbers remain intact,
and we inherit the security parameters from the original connection.  The
new replay attacks go away, as do most of the "new and exciting" ways to
PWN TLS 1.3 0-RTT.

The new tickets could still be supported to enable advanced operators the
flexibility they need to implement stateless 0-RTT, but from the TLS point
of view, it would just be a 0-RTT resume using a session ID, with
additional ticket data.  If the admins at a particular company want to
stuff all the session state into the ticket and accept the security
consequences of stateless 0-RTT resumption, I think they should have the
flexibility to do that.  I _think_ the new tickets give them what they need.

This would enable the standard 0-RTT resume to be as secure as keeping the
connection alive the whole time.  I think it would stop this "race to the
bottom" problem people are worried about on this thread.

So... how dumb is this idea?

Bill

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 14 Mar 2016 08:23:08 +0200

> intrinsically safe for (the vast majority) of the internet to enable and

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Mar 2016 04:32:09 -0700

On Sun, Mar 13, 2016 at 8:51 PM, Colm MacCárthaigh <[email-masked]>
wrote:

> On Sun, Mar 13, 2016 at 4:14 AM, Stephen Farrell <
> [email-masked]> wrote:
>
> 2. Give the recipient a chance to a get a head-start on servicing some
> kind of request.
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Mar 2016 04:39:00 -0700

On Sun, Mar 13, 2016 at 9:29 PM, Bill Cox <[email-masked]> wrote:

> On Sun, Mar 13, 2016 at 6:26 PM, Harlan Lieberman-Berg <
> [email-masked]> wrote:
>

Isn't this more or less what we have been calling PSK-resumption? Can you
explain
the difference?
-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 14 Mar 2016 13:10:32 +0100

On Sun, 2016-03-13 at 13:38 +0100, Eric Rescorla wrote:
> need to advertise it and are free to (a) not offer clients the
> ability to send

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

---

From: Kyle Nekritz <[email-masked]>
Date: Mon, 14 Mar 2016 14:52:47 +0000

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:[email-masked]] On Behalf Of Bill Cox
Sent: Sunday, March 13, 2016 6:23 PM
To: Scott Schmit <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Sun, Mar 13, 2016 at 2:23 PM, Scott Schmit <[email-masked]<mailto:[email-masked]>> wrote:

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.

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

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.

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?

Bill

---

From: Bill Cox <[email-masked]>
Date: Mon, 14 Mar 2016 08:35:25 -0700

> Isn't this more or less what we have been calling PSK-resumption? Can you

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

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 14 Mar 2016 09:10:05 -0700

> documented session-ID (and let's bring back the timestamp, too, since we'll

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

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 14 Mar 2016 09:15:17 -0700

> early data; and transferring the envelope key only once the session has

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.

> 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

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 14 Mar 2016 09:34:48 -0700

On Sun, Mar 13, 2016 at 12:04 PM, Bill Cox <[email-masked]> 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

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 14 Mar 2016 13:36:27 -0400

> On Mar 13, 2016, at 7:14 AM, Stephen Farrell <[email-masked]> wrote:
> 

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.

---

From: Subodh Iyengar <[email-masked]>
Date: Mon, 14 Mar 2016 18:04:07 +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.

Subodh

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

--
        Viktor.

_______________________________________________
TLS mailing list
[email-masked]
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=

---

From: Watson Ladd <[email-masked]>
Date: Mon, 14 Mar 2016 11:19:03 -0700

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

---

From: Subodh Iyengar <[email-masked]>
Date: Mon, 14 Mar 2016 18:27:24 +0000

> 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 [[email-masked]]
Sent: Monday, March 14, 2016 11:19 AM
To: Subodh Iyengar
Cc: [email-masked]
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

> 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 encount…

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

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.
> From: TLS [[email-masked]<mailto:[email-masked]>] on behalf of Viktor Dukhovni [[email-masked]<mailto:[email-masked]>]
> To: [email-masked]<mailto:[email-masked]>
> > On Mar 13, 2016, at 7:14 AM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:
> >
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> 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=>

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 14 Mar 2016 11:29:19 -0700

> impact of infinite replayable data for TLS, making it reasonably replay

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

---

From: Bill Cox <[email-masked]>
Date: Mon, 14 Mar 2016 11:38:27 -0700

> and more flexible, for the state to be around the action? like some kind of

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.

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

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

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 14 Mar 2016 11:40:52 -0700

On Mon, Mar 14, 2016 at 11:27 AM, Subodh Iyengar <[email-masked]> 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

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 14 Mar 2016 20:41:53 +0200

> > early data; and transferring the envelope key only once the session has

Unfortunately, that doesn't work for things like protocol banners or
other things that can be sent in 0-RTT and replied to in 0.5-RTT.

(Also, with regards to my comment about cryptographic screwedness,
such screwedness is not inherent in DH-0RTT, but is consequence of
the current implementation).

-Ilari

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 14 Mar 2016 11:57:09 -0700

> the current implementation).

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

-- 
Colm

---

From: Geoffrey Keating <[email-masked]>
Date: 14 Mar 2016 12:12:51 -0700

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

However, just because this is true for two sequential GET requests, it
may not be the case for a series of requests.  For example, a GET
followed by a PUT followed by another GET.  If the second GET is
performed by an attacker, it might reveal that the PUT has occurred
and the new size of the result.

Further issues can occur depending on the application.  For example,
if the result contains a timestamp, some sensitive numeric data, and
is compressed, then repeated queries will leak information about the
numeric data at a higher rate than if the attacker had to rely on
passive monitoring.

So, I don't think HTTP is generally safe against attacker-forced
replay, and would suggest great caution in allowing it.  Perhaps we
could say, in the TLS RFC or a new RFC covering the topic, that it
should only be allowed by servers and clients when serving/requesting
immutable static data, that is for requests that will only ever return
one result.

---

From: Bill Cox <[email-masked]>
Date: Mon, 14 Mar 2016 12:16:34 -0700

On Mon, Mar 14, 2016 at 11:57 AM, Colm MacCárthaigh <[email-masked]>
wrote:

>
>
> On Mon, Mar 14, 2016 at 11:41 AM, Ilari Liusvaara <
> [email-masked]> wrote:
>>
> This is interesting ... is there a way to do it that would preserve
> forward secrecy?
>

Replay resistance requires server-side state.  If that state includes
session decryption keys and we want PFS, then these keys need to be
encrypted using keys held by the client, which is not possible in DH
0-RTT.  Therefore the session keys cannot be saved on the server, and the
0-RTT data cannot be encrypted using anything but the server's static
keyshare, which is not fully PFS.  I see no way to implement real PFS in
the existing DH 0-RTT scheme.  However, I consider a few days of non-PFS to
be good enough.

Bill

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 14 Mar 2016 12:23:25 -0700

On Mon, Mar 14, 2016 at 12:12 PM, Geoffrey Keating <[email-masked]>
wrote:

> replay, and would suggest great caution in allowing it.
>

It's worth keeping in mind this recent paper about Replay attacks against
HTTPS <http://blog.valverde.me/2015/12/07/bad-life-advice/#.VucOsJMrIxN>.
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.

---

From: Dave Garrett <[email-masked]>
Date: Mon, 14 Mar 2016 15:25:28 -0400

(This thread has gotten long and winding, so I'm replying to these two portions bellow under a new subject. Reply after quotations.)

On Monday, March 14, 2016 02:38:27 pm Bill Cox wrote:
> On Mon, Mar 14, 2016 at 9:10 AM, Colm MacCárthaigh <[email-masked]> wrote:

> vastly different from the security requirements of a 0rtt protocol.

Previous discussion seemed to land on the conclusion that semi-static DH 0RTT should be defined in a separate document, and after this discussion I'm beginning to agree that all stateless 0RTT should be defined as a separate companion document to the main TLS 1.3 specification. We can likely agree on defining a stateful 0RTT PSK resumption system which is sufficiently safe and mistake-resistant, and we could restrict the official TLS 1.3 spec to only specify that, whilst referencing the other document as a more experimental feature that could be available to certain applications (possibly a non-standards-track document). HTTPS could then, itself, have a separate document laying out the necessary practices to do stateless 0RTT safely, and other applications should be warned that without a similar such document, things are very risky.

Is this in the ballpark of what the WG could agree on to help mitigate some of the problems here?

Dave

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 14 Mar 2016 19:25:57 +0000

> 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

---

From: Bill Cox <[email-masked]>
Date: Mon, 14 Mar 2016 12:32:50 -0700

> replay safety for applications should be compromised.

I agree that the default mode of operation needs to be secure and safe.
Since 0-RTT is so important for TLS 1.3, I would favor making the default
0-RTT mode secure.

> which incidentally are also a little more robust against traffic analysis.

Exactly.  Stateful 0-RTT session resumption can get us there, I think.  The
simplest approach I can think of is to use session caches.  If we don't
mind some PFS loss (comparable to what we got in TLS 1.2), the
straight-forward 0-RTT solution seems to work.

Bill

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Mar 2016 12:32:51 -0700

On Mon, Mar 14, 2016 at 12:25 PM, Dave Garrett <[email-masked]>
wrote:

> (This thread has gotten long and winding, so I'm replying to these two
> portions bellow under a new subject. Reply after quotations.)
>
> Previous discussion seemed to land on the conclusion that semi-static DH
> 0RTT should be defined in a separate document, and after this discussion
> I'm beginning to agree that all stateless 0RTT should be defined as a
> separate companion document to the main TLS 1.3 specification. We can
> likely agree on defining a stateful 0RTT PSK resumption system which is
> sufficiently safe and mistake-resistant, and we could restrict the official
> TLS 1.3 spec to only specify that, whilst referencing the other document as
> a more experimental feature that could be available to certain applications
> (possibly a non-standards-track document). HTTPS could then, itself, have a
> separate document laying out the necessary practices to do stateless 0RTT
> safely, and other applications should be warned that without a similar such
> document, things are very risky.
>

As far as I can tell, there's no protocol difference between "stateful" and
"stateless" resumption.
You use the same techniques (a replay cache) and the question is merely
whether the server
actually maintains one.

-Ekr

---

From: Geoffrey Keating <[email-masked]>
Date: 14 Mar 2016 13:17:07 -0700

> at will. ​As a result, it's not clear that 0-RTT replay makes this

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.

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 14 Mar 2016 13:47:43 -0700

On Mon, Mar 14, 2016 at 12:25 PM, Salz, Rich <[email-masked]> 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.
>

I was responding to a comment about HTTP, though :> I agree that the
implications of 0-RTT for other applications will be different.​

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 14 Mar 2016 13:47:51 -0700

On Mon, Mar 14, 2016 at 1:17 PM, Geoffrey Keating <[email-masked]> wrote:

> > HTTPS <http://blog.valverde.me/2015/12/07/bad-life-advice/#.VucOsJMrIxN
> >.

​Right. I'm not trying to argue that these two things are the same. I am
trying to point out that HTTPS replay attacks are *already* possible. So
from an HTTP developer perspective, developers already need to deal with
this issue. There are surely things we can do constrain the replay-ability
of 0-RTT​ data and I'm happy to see that happen. However, I don't want to
throw out 0-RTT completely for fear that it will expose HTTP to a new class
of attacks, since HTTP is already exposed to those attacks.

Cheers,

Ryan

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 14 Mar 2016 13:49:56 -0700

> 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

---

From: Kyle Nekritz <[email-masked]>
Date: Mon, 14 Mar 2016 21:14:46 +0000

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:[email-masked]] On Behalf Of Colm MacCárthaigh
Sent: Monday, March 14, 2016 2:29 PM
To: Subodh Iyengar <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

On Mon, Mar 14, 2016 at 11:04 AM, Subodh Iyengar <[email-masked]<mailto:[email-masked]>> 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

---

From: Bill Cox <[email-masked]>
Date: Mon, 14 Mar 2016 15:03:23 -0700

> at will. ​As a result, it's not clear that 0-RTT replay makes this

Yay, this attack is finally published.  Now I can argue that stateful 0-RTT
resumption is secure enough to be the default 0-RTT connection mode in TLS
1.3.

Summary: The stateless 0-RTT modes currently described in the TLS 1.3 spec
are somewhat dangerous and should be used with caution and only by admins
who know what they are doing.  In contrast, 0-RTT resumption from session
caches has almost the same security as session resumption in TLS 1.2.
This should be the default 0-RTT mode in TLS 1.3, IMO, though stateless PSK
0-RTT should also be supported to allow advanced users to achieve even
higher performance.

The attack in the paper is important because it explains why I do not care
about the following attack, at least for HTTPS.  Suppose a company has
properly implemented 0-RTT resumption using session caches.  They support
strong client auth, full PFS, and would like to think they prevent replay
attacks.  This is a large company with non-synchronized session caches in
data centers around the world.  The has the following steps:

- The attacker captures 0-RTT packets intended for a local data center, and
holds onto them without letting them through (yet).
- The attacker also sends a copy of these packets to a remote data center.
- The remote data center, since it does not have the session cached, drops
to a 1-RTT handshake.
- The TLS layer in the client completes the 1-RTT handshake, and then
resends the 0-RTT data, as required by the TLS 1.3 spec.  This is accepted
by the remote data center.
- The attacker simultaneously sends the local data center the initial 0-RTT
packets, which are accepted by the local data center because the session is
in the cache.

If this were HTTPS traffic, this attack would work against TLS 1.2, because
the browser would resend the packets rather than the TLS layer.  In any
case attackers can replay _any_ HTTPS packet using the attack from the
paper.  This attack gains the attacker nothing new against HTTPS.

Because of this, I recommend that POST requests be allowed as 0-RTT data
over session-cache based stateful 0-RTT resumption, but not over stateless
0-RTT resumption.  The ability for an eavesdropper to infinitely replay
0-RTT data is specific to stateless 0-RTT resumption.

So, is there any application that cares about this attack?  Consider ssh
using TLS 1.3, with 0-RTT to accelerate how fast a user's command is
executed.  Clearly, we cannot allow the user's command to be executed
twice.  Even if the destination machine is a VM in the cloud, eventually
the connection is routed to the same virtual machine for both connections.
The session cache on that machine would get a hit on the first connection,
and execute the user's command.  The second set of packets would be
rejected because the session resume count would be wrong.  I see no way for
an attacker to succeed in a replay attack.

In general, I expect applications that are inherently sensitive to replay
(such as ssh) to terminate all TLS connections in the same place, where the
session cache is shared and synchronized.  Otherwise, random network errors
would be a huge problem.  Distributed applications such as HTTP that
terminate all over the place have had to deal with random replay issues
from the beginning, which is why no one is seems to be terribly upset by
the attack described in the paper.

Stateful 0-RTT resumed sessions can provide significant security guarantees
not offered by stateless 0-RTT:

- Effective, although imperfect, reply defense, which is good enough for
real-world deployment in most cases (are there any counter-examples?)
- Strong client auth works: even a replay attack will fail to forge a proof
of possession or cause a server to accept a signature twice.
- PFS is possible, unlike with DH 0-RTT, although it also can be done with
stateless PSK 0-RTT (a good reason to prefer PSK 0-RTT over DH 0-RTT)

The only new security concern I see compared to TLS 1.2 session resumption
is that the TLS layer sometimes will replay packets on its own without
involving the application layer.  This appears not to be a problem for
HTTPS and other protocols that already replay packets when there are
network errors.  For other applications, it should be carefully considered
before choosing to use session-ID based 0-RTT resumption, but I expect it
to be safe for protocols that already have to deal with noisy network
connections.

Bill

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Mar 2016 18:46:11 -0700

On Mon, Mar 14, 2016 at 11:38 AM, Bill Cox <[email-masked]> wrote:

>> 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.
>>
>
> - encrypt the session cache entry with the session encryption key stored
> in the ticket

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

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 15 Mar 2016 09:50:40 +0200

> You use the same techniques (a replay cache) and the question is merely

Agreed. If the server maintains replay cache, one gets replay limited to
one per 0RTT connection even with DH-0RTT. And without server replay
cache, one gets near-infinite replay per 0RTT connection, no matter
what client does (other than 0*$VERYLARGE=0).

-Ilari

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Mar 2016 07:55:06 +0000

> You use the same techniques (a replay cache) and the question is merely

Experience with "replay caches" in Kerberos shows that they don't
work in the vast majority of cases.  Protocols need to be safe
without replay caches.

-- 
	Viktor.

---

From: Hubert Kario <[email-masked]>
Date: Mon, 21 Mar 2016 20:40:07 +0100

On Monday 14 March 2016 12:12:51 Geoffrey Keating wrote:
> > > 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:
> 

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Mar 2016 10:45:32 +1100

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

---

From: Hubert Kario <[email-masked]>
Date: Tue, 22 Mar 2016 11:59:30 +0100

On Tuesday 22 March 2016 10:45:32 Martin Thomson wrote:
> > Only in theory, in practice you can do most of the same things in
> > GET's as you can in POSTs.
> > 

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