Re: [TLS] Security review of TLS1.3 0-RTT

[Yoav Nir]

> On 5 Jun 2017, at 6:06, Bill Cox  wrote:
> 
> On Sun, Jun 4, 2017 at 4:08 PM, Benjamin Kaduk  > wrote:
> 
> Do we have a good example of why a non-safe HTTP request in 0-RTT would lose 
> specific properties required for security?  If so, that seems like a good 
> thing to include in the TLS 1.3 spec as an example of what can go wrong.
> 
> -Ben
> 
> I like the example of a POST request saying "send Alice $10".  It is a 
> request that sophisticated web services will avoid, yet many smaller and less 
> security savvy sites will continue to support requests like this, so I think 
> it is worth considering.
> 

I once saw a router with an HTTPS administration UI that would respond as you’d 
expect to:

GET mainpage.html?action=rebootDevice

Worse. The router was a firewall and this worked:

GET mainpage.html?action=disablePolicy

Yes.  GET. POST also worked, but for some reason the WebUI generated POSTs.

Of course, it was really secure because the GET was accompanied by a cookie, 
but I guess the cookie would fit in the early data. Not sure if it would 
survive a reboot, though.

Yoav





signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Security review of TLS1.3 0-RTT

[Benjamin Kaduk]

On 06/01/2017 03:50 PM, Victor Vasiliev wrote:
>
> To clarify, I am not suggesting that two streams would help. 
> I completely
> agree with you that two streams is not going to mitigate the
> DKG attack or
> others.  What I meant is that 0-RTT inherently has slightly
> different
> properties from 1-RTT and must be used with that in mind. 
> Specifically, I
> meant that it will not be enabled for applications by default,
> and HTTP clients
> would only allow it for methods that RFC 7231 defines as safe.
>
>
> Well in the real world, I think it'll be pervasive, and I even
> think it /should/ be. We should make 0-RTT that safe and remove
> the sharp edges. 
>
>
> Are you arguing that non-safe requests should be allowed to be sent
> via 0-RTT?
> Because that actually violates reasonable expectations of security
> guarantees
> for TLS, and I do not believe that is acceptable.
>

Do we have a good example of why a non-safe HTTP request in 0-RTT would
lose specific properties required for security?  If so, that seems like
a good thing to include in the TLS 1.3 spec as an example of what can go
wrong.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Benjamin Kaduk]

On 06/02/2017 04:49 PM, Victor Vasiliev wrote:
>
> 4. If implemented properly, both a single-use ticket and a
>strike-register style mechanism make it possible to limit
>the number of 0-RTT copies which are processed to 1 within
>a given zone (where a zone is defined as having consistent
>storage), so the number of accepted copies of the 0-RTT
>data is N where N is the number of zones.
>
>
> Correct.  Session caches are inherently bound to a single zone.

I think we covered this in a couple other messages in a different
subthread, but to be super-clear, 1-RTT session caches can be scoped to
a larger zone than 0-RTT acceptability, at the server's unilateral
discretion.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Benjamin Kaduk]

On 06/04/2017 02:08 PM, Bill Cox wrote:
> My feeling is that when talking to stateless 0-RTT servers, browsers
> should send only idempotent HTTP requests, and accept
> less-than-perfect FS.  I also feel they should avoid attempts at
> client auth over 0-RTT.  However, when talking to servers that prevent
> replay (but not re-transmission) I think browsers should be free to
> send any HTTP requests over 0-RTT, and also attempt client auth.  The
> security properties of 0-RTT data are still different, but for
> browsers, where it does not matter whether the re-transmission is in
> the browser or TLS layer, the security seems equivalent to me.

I think we're at a point where multiple people have expressed what their
(subjective) feeling on the desired behavior is, and those feelings are
not in agreement.

So, some more concrete reasoning and deductions seem required in order
for such contributions to be useful towards reaching consensus.

-Ben

P.S. It seems pretty well established that a client will not in general
have a good idea whether it's talking to a server that prevents replay
or is stateless.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Fri, Jun 2, 2017 at 2:25 PM, Eric Rescorla  wrote:
>
> Sure. For the sake of clarify, I'm going to suggest we call:
>
> - replay == the attacker re-sends the data with no interaction
> with the client
> - retransmission == the client re-sends (possibly with some slight
> changes)
>

O.k., cool.


> 7. With the current design, clients have no way of knowing what, if any,
>anti-replay mechanisms the servers are using. Thus, they cannot be
>sure that servers are ensuring at-most-once semantics for the 0-RTT
>data (at-most-twice if the client retransmits in response to 0-RTT
>failure) [0]. This makes it difficult for clients to know what is
>safe to send in 0-RTT.
>
> 8. The more broadly distributed the information required to process
>a session ticket (on the server), the worse the FS situation is,
>with session tickets encrypted under long-lived keys being the
>worst.
>
> I note that you suggest separating out 0-RTT tickets and resumption
> tickets, but I don't actually see how that changes matters. As Ilari
> notes, it is possible to say that a ticket cannot be used for 0-RTT
> and if you have a ticket which can be used for resumption globally
> but for 0-RTT at just one site, the server can implement that policy
> unilaterally.
>

Yep, that's right, and should work.


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

Re: [TLS] Security review of TLS1.3 0-RTT

[Bill Cox]

On Fri, Jun 2, 2017 at 2:39 PM, Victor Vasiliev  wrote:

>
> Now, imagine the following attack:
>
>   a) Between (1) and (2), the attacker resets the TCP connection, after
>  the client got the response and the session ticket.
>   b) Since the client has the ticket, it 0-RTTs the POST to take out a
>  lock.
>   c) Attacker redirects the client to another datacenter, which cannot
>  accept 0-RTT, so it switches to 1-RTT.
>   d) During (b) and (c), the attacker records a transcript of 0-RTT
>  request to take out a lock.
>   d) The rest of (2)-(6) proceed in normal fashion via client talking to
>  the distant datacenter.
>   e) Attacker replays the lock being taken out in the datacenter where
>  0-RTT would succeed; the lock now is in place, and the client has
>  no idea about it.
>
> Because the application layer cannot reasonably assume that such
> reordering can happen, it is not acceptable to 0-RTT the POST in #2.
>

A simpler attack over TLS 1.2 that has the same result:

a) An active attacker waits until she sees what she believes is a lock POST
request.  This can happen at any time during the connection, and the flight
is identified by metadata since it is encrypted.
b) The attacker holds the lock request, and keeps the connection to the
server alive by transmitting a byte to it every minute or so, and
terminates the client connection.
c) The client reconnects, and proceeds with steps 2-6
d) Attacker sends the request to obtain the lock, and now the resource is
locked.

For browsers, this attack seems simpler (no redirect to another data
center), and more powerful (can attack at any point in the stream).  It
obtains the same result (locked resource), and I do not see any simple
mitigation, other than to force clients to make all state changes
transactional.  I realize this attack requires browser retransmition, not
just TLS re-transmission, so it is fundamentally different.  However, isn't
the result the same or worse?

My feeling is that when talking to stateless 0-RTT servers, browsers should
send only idempotent HTTP requests, and accept less-than-perfect FS.  I
also feel they should avoid attempts at client auth over 0-RTT.  However,
when talking to servers that prevent replay (but not re-transmission) I
think browsers should be free to send any HTTP requests over 0-RTT, and
also attempt client auth.  The security properties of 0-RTT data are still
different, but for browsers, where it does not matter whether the
re-transmission is in the browser or TLS layer, the security seems
equivalent to me.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Ilari Liusvaara]

On Fri, Jun 02, 2017 at 05:49:51PM -0400, Victor Vasiliev wrote:
> On Thu, Jun 1, 2017 at 8:22 PM, Eric Rescorla  wrote:
> 
> > I've just gone through this thread and I'm having a very hard time
> > understanding what the actual substantive argument is about.
> >
> 
> I believe at this point we mostly disagree on what specific scenarios
> are and are not a concern that should be solved by TLS layer.
> Replay/retry distinction might be at core for some disagreements.
> 
> Let me lay out what I think we all agree on.
> >
> > 1. As long as 0-RTT is declinable (i.e., 0-RTT does not cause
> >connection failures) then a DKG-style attack where the client
> >replays the 0-RTT data in 1-RTT is possible.
> >
> 
> Correct.

Err, how does not failing connection enable DKG-style attack?

If connection failed on 0-RTT failure, the client would then
presumably just establish a new one (if it can) without 0-RTT,
and we are where we started (the client doesn't even gain
additional knowledge, because 0-RTT ACK exists today).
 
But failing the connection on 0-RTT failure is not nice on
other grounds.

> >
> > 3. Allowing the attacker to generate an arbitrary number of 0-RTT
> >replays without client intervention is dangerous even if
> >the application implements replay-safe semantics.
> >
> 
> Correct, and the specific number is highly situational.

For some attacks, it is pretty low (few dozens or less or so),
especially if you can distribute across servers.

> > 4. If implemented properly, both a single-use ticket and a
> >strike-register style mechanism make it possible to limit
> >the number of 0-RTT copies which are processed to 1 within
> >a given zone (where a zone is defined as having consistent
> >storage), so the number of accepted copies of the 0-RTT
> >data is N where N is the number of zones.
> >
> 
> Correct.  Session caches are inherently bound to a single zone.

Which together with "multi-server" attacks imply that 0-RTT tickets
need to be bound to a zone (when doing 0-RTT).

Of course, even only using tickets for 0-RTT in one zone, while
accepting them to skip signatures on others would still leave the
FS problems.

> > 5. Implementing the level of coherency to get #4 is a pain.
> >
> 
> Yes.

Interestingly, the required coherency is quite easy for small sites
(run off VPS or container), it is large sites (multiple datacenters)
that have problems.



-Ilari

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Victor Vasiliev]

On Thu, Jun 1, 2017 at 8:22 PM, Eric Rescorla  wrote:

> I've just gone through this thread and I'm having a very hard time
> understanding what the actual substantive argument is about.
>

I believe at this point we mostly disagree on what specific scenarios
are and are not a concern that should be solved by TLS layer.
Replay/retry distinction might be at core for some disagreements.

Let me lay out what I think we all agree on.
>
> 1. As long as 0-RTT is declinable (i.e., 0-RTT does not cause
>connection failures) then a DKG-style attack where the client
>replays the 0-RTT data in 1-RTT is possible.
>

Correct.


> 2. Because of point #1, applications must implement some form
>of replay-safe semantics.
>

Correct.


>
> 3. Allowing the attacker to generate an arbitrary number of 0-RTT
>replays without client intervention is dangerous even if
>the application implements replay-safe semantics.
>

Correct, and the specific number is highly situational.


>
> 4. If implemented properly, both a single-use ticket and a
>strike-register style mechanism make it possible to limit
>the number of 0-RTT copies which are processed to 1 within
>a given zone (where a zone is defined as having consistent
>storage), so the number of accepted copies of the 0-RTT
>data is N where N is the number of zones.
>

Correct.  Session caches are inherently bound to a single zone.


> 5. Implementing the level of coherency to get #4 is a pain.
>

Yes.


> 6. If you bind each ticket to a given zone, then you can
>get limit the number of accepted 0-RTT copies to 1
>(for that zone) and accepted 1-RTT copies to 1 (because
>of the DKG attack listed above).
>
>
Correct.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Eric Rescorla]

It's still there, in 4.6.1.

"The sole extension currently defined for NewSessionTicket is “early_data”,
indicating that the ticket may be used to send 0-RTT data (Section 4.2.9
)). It contains
the following value:"

-Ekr


On Fri, Jun 2, 2017 at 12:57 AM, Ilari Liusvaara 
wrote:

> On Thu, Jun 01, 2017 at 11:20:56PM -0700, Colm MacCárthaigh wrote:
> >
> > Maybe a lot of this dilemma could be avoided if the the PSKs that can be
> > used for regular resumption and for 0-RTT encryption were separate, with
> > the latter being scoped smaller and with use-at-most-once semantics.
>
> The problem here is that the scoping rules can be impossible for the
> client to understand (there is possibly anycast involved!)
>
>
> And also, more serious problem: I thought that server could send
> tickets that can't be used for 0-RTT. And this was true a few drafts
> back, but now it seems to have gotten lost (at least I can't find
> the appropriate requirements). This is a problem, because it forces
> any server that implements tickets to deal with at least ignoring
> 0-RTT (trial decryptions!). Which is complexity that I rather not
> have in servers that don't truly implement 0-RTT.
>
>
>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Security review of TLS1.3 0-RTT

[Ilari Liusvaara]

On Thu, Jun 01, 2017 at 11:20:56PM -0700, Colm MacCárthaigh wrote:
> 
> Maybe a lot of this dilemma could be avoided if the the PSKs that can be
> used for regular resumption and for 0-RTT encryption were separate, with
> the latter being scoped smaller and with use-at-most-once semantics.

The problem here is that the scoping rules can be impossible for the
client to understand (there is possibly anycast involved!)


And also, more serious problem: I thought that server could send
tickets that can't be used for 0-RTT. And this was true a few drafts
back, but now it seems to have gotten lost (at least I can't find
the appropriate requirements). This is a problem, because it forces
any server that implements tickets to deal with at least ignoring
0-RTT (trial decryptions!). Which is complexity that I rather not
have in servers that don't truly implement 0-RTT.



-Ilari

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Thu, Jun 1, 2017 at 5:22 PM, Eric Rescorla  wrote:

> I've just gone through this thread and I'm having a very hard time
> understanding what the actual substantive argument is about.
>
> Let me lay out what I think we all agree on.
>

This is a good summary, I just have a few clarifications ...


> 1. As long as 0-RTT is declinable (i.e., 0-RTT does not cause
>connection failures) then a DKG-style attack where the client
>replays the 0-RTT data in 1-RTT is possible.
>

This isn't what I call a replay. It's a second request, but the client is
control of it. That distinction matters because the client can modify it if
it needs to be unique in some way and that turns out to be important for
some cases.

2. Because of point #1, applications must implement some form
>of replay-safe semantics.
>

Yep; though note that in some cases those replay-safe semantics themselves
actually depend on uniquely identifiable requests. For example a protocol
that depends on client-side-versioning, or the token-binding case.


> 3. Allowing the attacker to generate an arbitrary number of 0-RTT
>replays without client intervention is dangerous even if
>the application implements replay-safe semantics.
>

Yep.


> 4. If implemented properly, both a single-use ticket and a
>strike-register style mechanism make it possible to limit
>the number of 0-RTT copies which are processed to 1 within
>a given zone (where a zone is defined as having consistent
>storage), so the number of accepted copies of the 0-RTT
>data is N where N is the number of zones.
>

This is much better than the total anarchy of allowing completely unlimited
replay, and it does reduce the risk for side-channels, throttles etc, but I
wouldn't consider it a proper implementation or secure. Importantly it gets
us back to a state where clients may have no control over a deterministic
outcome.

Some clients need idempotency tokens that are consistent for duplicate
requests, this approach works ok then. Other kinds of clients also need
tokens that are unique to each request attempt, this approach doesn't work
ok in that case. That's the qualitative difference.

I'd also add that the suggested optimization here is clearly to support
globally resumable session tickets that are not scoped to a single site.
That's a worthy goal; but it's unfortunate that in the draft design it also
means that 0-RTT sections would be globally scoped. That's seems bad to me
because it's so hostile to forward secrecy, and hostile to protecting the
most critical user-data. What's the point of having FS for everything
except the requests, where the auth details often are, and which can
usually be used to generate the response? Synchronizing keys that can
de-cloak an arbitrary number of such sessions to many data centers spread
out across the world, seems just so defeating. I realize that it's common
today, I've built such systems, but at some point we have to decide that FS
either matters or it doesn't. Are users and their security auditors really
going to live with that? What is the point of rolling out ECDHE so
pervasively only to undo most of the benefit?

Maybe a lot of this dilemma could be avoided if the the PSKs that can be
used for regular resumption and for 0-RTT encryption were separate, with
the latter being scoped smaller and with use-at-most-once semantics.

5. Implementing the level of coherency to get #4 is a pain.
>
> 6. If you bind each ticket to a given zone, then you can
>get limit the number of accepted 0-RTT copies to 1
>(for that zone) and accepted 1-RTT copies to 1 (because
>of the DKG attack listed above).
>

Yep! Agreed :)

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Thu, Jun 1, 2017 at 1:50 PM, Victor Vasiliev  wrote:

> I am not sure I agree with this distinction.  I can accept the difference
> in
> terms of how much attacker can retry -- but we've already agreed that
> bounding
> that number is a good idea.  I don't see any meaningful distinction in
> other
> regards.
>

It's not just a difference in the number of duplicates. With retries, the
client maintains some control, so it can do things like impose delays and
update request IDs. Bill followed up with an exactly relevant example from
Token Binding where the retry intentionally has a different token value.
That kind of control is lost with attacker driven replays.

But even if we focus on just the number; there is something special about
allowing 0 literal replays of a 0-RTT section; it is easy for users to
confirm/audit/test. If there's a hard-guaranteee that 0-RTT "MUST" never be
replayable, then I feel like we have a hope of producing a viable 0-RTT
ecosystem. Plenty of providers may screw this up, or try to cut corners,
but if we can ensure that they get failing grades in security testing
tools, or maybe even browser warnings, then we can corral things into a
zone of safety. Otherwise, with no such mechanism, I fear that bad
operators will cause the entire 0-RTT feature to be tainted and entirely
turned off over time by clients.

>
> Sure, but this is just an argument for making N small.  Also, retrys can
> also
> be directed to arbitrary nodes.
>

This is absolutely true, but see my point about the client control.
Regardless, it is a much more difficult attack to carry out. That is to
intercept and rewrite a whole TCP connection Vs grabbing a 0-RTT section
and sending it again.


>
>
>> What concerns me most here is that people are clearly being confused by
>> the TLS 1.3 draft into mis-understanding how this interacts with 0-RTT. For
>> example the X-header trick, to derive an idempotency token from the binder,
>> that one experimental deployment innovated doesn't actually work because it
>> doesn't protect against the DKG attack. We're walking into rakes here.
>>
>
> Of course it doesn't protect against the DKG attack, but nothing at that
> layer
> actually does.
>
> This sounds like an issue with the current wording of the draft.  As I
> mentioned, I believe we should be very clear on what the developers should
> and
> should not expect from TLS.
>

Big +1 :)


> So, in other words, since we're now just bargaining about the value of N,
>>> operational concerns are a fair game.
>>>
>>
>> They're still not fair game imo, because there's a big difference between
>> permitting exactly
>> one duplicate, associated with a client-driven retry, and permitting huge
>> volumes of replays. They enable different kinds of attacks.
>>
>>
> Sure, but there's a space between "one" and "huge amount".
>

It's not just quantitive, it's qualitative too. But now I'm duplicating
myself more than once ;-)


> Well in the real world, I think it'll be pervasive, and I even think it
>> /should/ be. We should make 0-RTT that safe and remove the sharp edges.
>>
>
> Are you arguing that non-safe requests should be allowed to be sent via
> 0-RTT?
> Because that actually violates reasonable expectations of security
> guarantees
> for TLS, and I do not believe that is acceptable.
>

I'm just saying that it absolutely will happen, and I don't think any kind
of lawyering about the HTTP spec and REST will change that. Folks use GETs
for non-idempotent side-effect-bearing APIs a lot. And those folks don't
generally understand TLS or have anything to do with it. I see no real
chance of that changing and it's a bit of a deceit for us to think that
it's realistic that there will be these super careful 0-RTT deployments
where everyone from the Webserver administrator to the high-level
application designer is coordinating and fully aware of all of the
implications. It crosses layers that are traditionally quite far apart.

So with that in mind, I argue that we have to make TLS transport as secure
as possible by default, while still delivering 0-RTT because that's such a
beneficial improvement.


> I do not believe that this to be the case.  The DKG attack is an attack
>>> that allows
>>> for a replay.
>>>
>>
>> It's not. It permits a retry. The difference here is that the client is
>> in full control. It can decide to delay, to change a unique request ID, or
>> even not to retry at all. But the legitimate client generated the first
>> attempt, it can be signaled that it wasn't accepted, and then it generates
>> the second attempt. If it really really needs to it can even reason about
>> the complicated semantics of the earlier request being possibly
>> re-submitted later by an attacker.
>>
>
> That's already not acceptable for a lot of applications -- and by enabling
> 0-RTT for non-safe HTTP requests, we would be pulling the rug from under
> them.
>

Yep; but I think /this/ risk is manageable and tolerable. Careful 

Re: [TLS] Security review of TLS1.3 0-RTT

[Ilari Liusvaara]

On Wed, May 31, 2017 at 03:49:03PM -0400, Victor Vasiliev wrote:
> On Tue, May 30, 2017 at 9:56 PM, Colm MacCárthaigh 
>  wrote:
> 
> > Here you argue, essentially, that it is too inconvenient to mitigate those
> > attacks for users. I don't think we can seriously take that approach.
> >
> > If the methods are too inconvenient, the secure alternative is to not use
> > 0-RTT at all.
> >
> > [snip]
> >
> 
> I think I am not getting my key point across here clearly.  I am not arguing
> that they are inconvenient, I am arguing that the guarantee you are trying
> to provide is impossible.

TLS level "sent data is delivered at most once" is very much possible.
But it requires synchronous state.

And it seems like where "few replays @TLS" would be easier than "no
replays @TLS", is where the replays would be to different servers, with
each server only accepting once. But "few replays" distributed among
different servers is much more dangerous than "few replays" to one
server.

Yes, residual replays will still come through even when TLS guarantees
"at most once" behavior. But turns out one already has to handle that
form of replay, due to wonders of web browser behavior (and reordering
attacks abusing timeouts). It is TLS not guaranteeing "at most once"
behavior (especially across servers) that enables new attacks.

This is fundamentially about what is REQUIRED to do 0-RTT without
nasty security holes. If you think this is too difficult, just don't
do 0-RTT. One extra RTT is a lot better than nasty attacks, with
potential consequences much worse than just some site getting DoSed
or some card chargebacks.



-Ilari

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Wed, May 31, 2017 at 12:49 PM, Victor Vasiliev 
wrote:

> I think I am not getting my key point across here clearly.  I am not
> arguing
> that they are inconvenient, I am arguing that the guarantee you are trying
> to
> provide is impossible.
>
> I wholeheartedly agree that if it is possible to provide guarantee B (zero
> replays), we really should provide it.  The problem is, we cannot.  Since
> 0-RTT
> is by its very design declinable, there will be always a possibility for at
> least one retry.
>

This is the part we agree on; but as I've said before, the kinds of attacks
enabled by these kinds of client-initiated retries, and by
attacker-initiated replays are fundamentally different.


> Once you concede you can have at least one replay, the difference between
> one
> replay and N replays (for all N > 0) is not that large, which is why I
> refer to
> this as "nebulous bound" (guarantee C).
>

There's a very big difference and it leads to real-world attacks. With many
replays, all sorts of side-channel analyses become possible, and I've
provided examples. It's particularly nasty that the replays can be
out-of-bound and to arbitrary nodes of the attacker's choosing, which makes
the attacks even more effective.


> Your applications already have to
> contend with replays, it's now just the matter of preventing side-channel
> amplification.
>

Yes; applications using 0-RTT do have to make themselves retry-tolerant,
 as they already must in many scenarios (e.g. a browser driven
application).  What concerns me most here is that people are clearly being
confused by the TLS 1.3 draft into mis-understanding how this interacts
with 0-RTT. For example the X-header trick, to derive an idempotency token
from the binder, that one experimental deployment innovated doesn't
actually work because it doesn't protect against the DKG attack. We're
walking into rakes here.

So, in other words, since we're now just bargaining about the value of N,
> operational concerns are a fair game.
>

They're still not fair game imo, because there's a big difference between
permitting exactly
one duplicate, associated with a client-driven retry, and permitting huge
volumes of replays. They enable different kinds of attacks.

I keep forgetting about forward secrecy in all of this, but it's worth
noting that your argument for globally resumable sessions also implies that
we shouldn't really shoot for  FS for some of the most critical user data.
I also find that bizarre.

To clarify, I am not suggesting that two streams would help.  I completely
> agree with you that two streams is not going to mitigate the DKG attack or
> others.  What I meant is that 0-RTT inherently has slightly different
> properties from 1-RTT and must be used with that in mind.  Specifically, I
> meant that it will not be enabled for applications by default, and HTTP
> clients
> would only allow it for methods that RFC 7231 defines as safe.
>

Well in the real world, I think it'll be pervasive, and I even think it
/should/ be. We should make 0-RTT that safe and remove the sharp edges.

>
> I do not believe that this to be the case.  The DKG attack is an attack
> that allows
> for a replay.
>

It's not. It permits a retry. The difference here is that the client is in
full control. It can decide to delay, to change a unique request ID, or
even not to retry at all. But the legitimate client generated the first
attempt, it can be signaled that it wasn't accepted, and then it generates
the second attempt. If it really really needs to it can even reason about
the complicated semantics of the earlier request being possibly
re-submitted later by an attacker.

Replays are different though; the attacker just literally copies the data
and can resend and resend as desired. As I've shown; this breaks real-world
things like authenticated throttling systems, and leads to side-channel and
cache analysis; where only very rarely is one attempt sufficient to
exploit.


> There is an enormous difference between a protocol that does not
> allow replays and the protocol that allows one.  For many applications, it
> only
> takes one replay for things to go terribly wrong.
>
>
>> The only place that the DKG attack can be mitigated is at application
>> layer.
>>
>
> Indeed.
>
>
>> The TLS APIs and different streams are pointless here.
>>
>
> I agree that different streams are pointless.  The only ways APIs can help
> is
> to not send replay-sensitive requests via 0-RTT, and to not accept those
> requests until peer liveness is confirmed.
>

This puts a massive smile on my face :)

>
> Indeed, but I am not suggesting we ignore those attacks.  The way I see
> this is
> that, originally when we did 0-RTT in QUIC, we had strike registers which
> are
> approximately what you are advocating.
>

Well I'd really advocate for single-use caches, because I think Forward
Secrecy is important :)


> We thought this provided property B
> (at-most-once semantics for 0-RTT), but at 

Re: [TLS] Security review of TLS1.3 0-RTT

[Ilari Liusvaara]

On Tue, May 30, 2017 at 05:38:02PM -0400, Victor Vasiliev wrote:



A couple points:

- Various mechanisms related to conserving IPv4 addresses can result
  client and server disagreeing about server IP address. Or even the
  address family.
- If one has limited number of replays, distributing those among
  multiple servers is the most dangerous.
- If you rely on sticky loadbalancer, you have to ensure that attacker
  can't send requests directly to the servers, bypassing the
  loadbalancer! In some architectures, it is rather easy to
  accidentially expose the backend servers, even if all the honest
  connections flow through the loadbalancer.
- Binders are computationally random, so if you want to shard on
  those for strike register, simple mod N scheme distributes the load
  well.
- 0-RTT scope can be written into tickets. The session ticket scope
  may be larger than that. Routing to datacenters should be relatively
  sticky.
- As noted, this mess with state is just necressary for security if
  you use 0-RTT.
- Could be good idea for clients to blacklist origins for tickets
  (meaning, use GDHE-CERT and possibly (GDHE-)static-PSK handshakes
  only) for some time if duplicate accepts are detected during
  grease testing. That should not cause any servers to actually
  break from user standpoint, since servers need to support those
  handshake modes anyway.


-Ilari

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Tue, May 30, 2017 at 2:38 PM, Victor Vasiliev  wrote:

> Thank you for your analysis!  I appreciate the attention to the security
> properties of the 0-RTT requests, as it is the more delicate part of the
> protocol.  It took me a while to get through the entire review, and there
> are
> many things on which I would like to comment, but if I do that for every
> one of
> them, this reply would be too long.  Hence, I’ll try to concentrate on the
> key
> points.
>

Thanks too for reading and the response!


> TLS 1.3 as-is does not remove any of the replay protection guarantees
> provided
> by TLS 1.2.  However, if the user chooses to waive said protection in
> order to
> do 0-RTT, they can do that with an API explicitly designed for that
> purpose.
>

I don't think this holds true;  the signs are that browsers and servers
will enable by default, with well-meaning limits on the kinds of requests.
But in the real-world; it'll absolutely be enabled lots, that's the point
after all. I hope we can have pervasive 0-RTT. It'll be awesome, because
the speed of light sucks.


>
> 3) Full replay protection for 0-RTT is not realistically feasible at TLS
> layer,
>because TLS layer is not the right place for that.
>
> You’ve already pointed out the existence of the DKG attack, where the
> attacker
> forces the client to retry the request with 1-RTT.  In this scenario, the
> attacker has a buffered 0-RTT request and is ready to insert it at any
> convenient point in time, violating the initial order assumptions.
>

Yep, though as I point out too, I think the DKG attack is different from
other replay attacks in ways that matter. The only place that the DKG
attack can be mitigated is at application layer. The TLS APIs and different
streams are pointless here. And I think that's actually an ok trade-off for
some kinds of applications - I don't think it should be a blocker for
0-RTT.  I think we agree on all this.


> With respect to the non-browser HTTP applications, I am not sure I am sold
> on
> the notion of “careful clients”. My understanding is that you suggest to
> treat
>
0-RTT failure as semantically equivalent to a regular connection failure,
> under
> the assumption that all of your clients already have to handle that case
> properly.  I see how this is supposed to work out, but most systems of this
> nature work well because connections succeed most of the time -- and as
> you go
> more and more towards the path of promising full replay protection, you
> will
> break more and more 0-RTT handshakes.  Both session resumption in general
> and
> 0-RTT in particular are designed with assumption that they can be declined
> at
> any point, that this is a normal and expected event, and at worst it would
> result in a minor performance degradation; “careful clients” violate that
> assumption.
>

The careful client is just to illustrate what it takes to make a
replay-safe application on top of an eventually consistent data store model
(which isn't uncommon) ... I don't think it's that realistic either, but it
was to point out that separate streams don't help. Only timings do.


> 4) Operational experience on datacenter-local strike registers is negative.
>
> We deployed strike registers in the initial QUIC deployment, and it was an
> operational hassle, so once we discovered that they do not provide full
> replay
> protection (due to all issues outlined above), the cost/benefit analysis
> became
> decidedly not in their favor.
>

The argument about operational inconvenience is irrelevant and dangerous.
It doesn't matter that it's hard. It doesn't matter how much it costs. It's
the cost of doing 0-RTT securely. Doing it insecurely should not be an
option, and shouldn't be something specified in an RFC.


> Our deployment experience also suggests that the negative impact from
> limiting
> 0-RTT to the same datacenter is not negligible.
>

This is the terribly false premise that gets to the heart of things. You
acknowledge yourself that there are attacks. Here you argue, essentially,
that it is too inconvenient to mitigate those attacks for users. I don't
think we can seriously take that approach.

If the methods are too inconvenient, the secure alternative is to not use
0-RTT at all.

The key phrase here "the negative impact from limiting 0-RTT to the same
datacenter is not negligible" is simply utterly the wrong way around. Yes,
it's true that fewer 0-RTT sections are accepted in a datacenter-local
system than if they are globally valid; but globally valid ones are not
secure; so what's the benefit of that comparison? It's not an alternative
we can responsibly consider. The only secure comparison is to not having
0-RTT at all. At least with datacenter local 0-RTT we do get /some/ 0-RTT.

So the statement should really be "Datacenter-local 0-RTT resumption allows
us to use 0-RTT at all, which is great, considering that it would otherwise
lead to side-channel and privacy-defeating attacks. What a 

Re: [TLS] Security review of TLS1.3 0-RTT

[Dave Garrett]

On Tuesday, May 30, 2017 05:38:02 pm Victor Vasiliev wrote:
> TLS isn’t a magical “transport security solution”, it provides a very specific
> set of explicit security guarantees to the applications that use it.  It can 
> be
> used as a building block for the secure systems, but at the end of the day, 
> the
> security of a system hinges on the designers’ understanding of the security
> contracts provided by individual components.
> 
> TLS 1.3 as-is does not remove any of the replay protection guarantees provided
> by TLS 1.2.  However, if the user chooses to waive said protection in order to
> do 0-RTT, they can do that with an API explicitly designed for that purpose.

+1; In fact, I'd suggest sticking this almost as-is into the spec somewhere.

>   C. “Nebulous” replay bound.  0-RTT data can be replayed, but only for some
>   finitely bounded number of times.  I initially wanted to call this “weak
>   replay protection”, but that felt too generous.
> 
> Normally I would dismiss this as a useful security property due to its 
> inherent
> vagueness, for the same reasons that “your server is too far away for
> nanosecond-level timing attacks on Intel CPUs” is a property that no serious
> cryptographer would admit in a research paper.  However, you’ve pointed out 
> some
> interesting side channel leaks, which exist even without 0-RTT, but can be
> amplified by replaying 0-RTT queries. C, like B, mitigates this, so this is a
> meaningful property to provide.
> 
> Let’s talk about what mechanisms are and are not viable for the nebulous
> bound promise.

There is one relatively straightforward mechanism for limiting 3rd party replay:
A 3rd party replaying 0-RTT PSK will fail to successfully complete the handshake
(after 1-RTT), as it would generally have the identity/ticket but not the key
behind it (e.g. resumption_master_secret). The 0-RTT data will have already been
processed, however a server detecting any PSK failure could then flag the
offending ticket/IP and reject all future 0-RTT attempts for some time period 
(e.g.
ticket lifetime). This would limit replays to one per server, or less if this 
banned
0-RTT state is shared across servers. The notable problem with this mechanism
is that a 0-RTT DDoS, could easily balloon the state size rather significantly, 
if not
careful. Servers would have to be fine with budgeting resources for a nontrivial
state in the event of attack, even if they don't need it during normal 
operation,
but that could at least be doable. A replay from the 1st party that is expected 
to
have the correct key/secret or from a 3rd party that has stolen it would not be
mitigated by this system, but that's much harder for an attacker to attempt, at
least.


Dave

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Benjamin Kaduk]

On 05/24/2017 10:32 AM, Colm MacCárthaigh wrote:
>
> > Another crazy idea would be to just say that servers MUST limit
> the use
> > of a single binder to at most 100 times, with the usual case
> being just
> > once, to allow for alternative designs that have weaker distributed
> > consensus requirements (but still describe these current two
> methods as
> > examples of ways to do so).
>
> You actually need strong distributed consensus about all accepted
> 0-RTT here.
>
>
> This pattern doesn't need strong consensus. If you have 10 servers,
> you could give each 10 goes at the ticket, and let each exhaust its 10
> attempts without any coordination or consensus. You likely won't get
> to "exactly 100", but you will get to "at most 100 times". 
>

Or (up to) 100 servers and give each server just one crack at the
ticket, which is perhaps more plausible to implement sanely.

> But the inner critical section would be inherently more complicated. 
> For the at most once case we need to a critical section that performs
> an exclusive-read-and-delete atomically. It's a mutex lock or a clever
> construction of atomic instructions.  For "at most N" we now need to
> perform a decrement and write in the critical section, and it becomes
> more like a semaphore. 
>
> It's probably not a pattern that's worth the trade-offs. 
>

That particular decrement-based design is not worth the trade-off,
definitely, but I doubt it's the only scheme that could meet the stated
requirement.  Something that attempts to access a global single-use data
structure but has some failure tolerance for that operation, and some
plausible story for bounding how often that can happen, say (like
stopping accepting 0-RTT at all on that server for 10 seconds once a
threshold level of errors occurs).

But, as indicated by the "crazy idea" prefix, I am not actually pushing
for this scheme.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Wed, May 24, 2017 at 7:30 AM, Ilari Liusvaara 
wrote:
>
> > Right, this would bring replays down from the millions hypothesized for
> > the weak time-based thing to more like tens, which is kind of in the
> > regime that we are currently in with (at least some) application
> behavior.
>
> Actually, even tens of replays at TLS level is quite dangerous,
> especially if to different servers (bad information leaks via cache
> attacks).
>

It hard stops replays, but does nothing about retries, and I think that's
ok. The client is in much more control of retries, and it's similar (if not
identical) to what can happen today with an interrupted TCP or TLS
connection. If a client permits hundreds, or millions of forced retries, I
think that's more appropriately handled at the client/application level,
but keep in mind there are typically seconds between the retries and the
rate of attack is slow.

Replays are when an attacker can send the same data at-will and it's
completely unknown to the client, it can happen out of band over different
network connectivity, in a very short and sharp interval of time, possibly
even to different server endpoints, and can be used by attackers to gather
information. These I think need to be mitigated at the TLS level; and
should be hard-stopped.

> Another crazy idea would be to just say that servers MUST limit the use
> > of a single binder to at most 100 times, with the usual case being just
> > once, to allow for alternative designs that have weaker distributed
> > consensus requirements (but still describe these current two methods as
> > examples of ways to do so).
>
> You actually need strong distributed consensus about all accepted
> 0-RTT here.
>

This pattern doesn't need strong consensus. If you have 10 servers, you
could give each 10 goes at the ticket, and let each exhaust its 10 attempts
without any coordination or consensus. You likely won't get to "exactly
100", but you will get to "at most 100 times".

But the inner critical section would be inherently more complicated.  For
the at most once case we need to a critical section that performs an
exclusive-read-and-delete atomically. It's a mutex lock or a clever
construction of atomic instructions.  For "at most N" we now need to
perform a decrement and write in the critical section, and it becomes more
like a semaphore.

It's probably not a pattern that's worth the trade-offs.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Ilari Liusvaara]

On Wed, May 24, 2017 at 08:50:07AM -0500, Benjamin Kaduk wrote:
> On 05/21/2017 05:47 PM, Eric Rescorla wrote:
> >
> >
> > On Sat, May 20, 2017 at 6:16 AM, Ilari Liusvaara
> > > wrote:
> >
> > On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote:
> >  
> >
> > - Clients MUST NOT use the same ticket multiple times for 0-RTT.
> >
> >
> > I don't understand the purpose of this requirement. As you note below,
> > servers are ultimately responsible for enforcing it, and it's not clear to
> > me why clients obeying it makes life easier for the server.
> >
> 
> I think it's just an attempt to make clear what the client behavior
> should be.  It's like when we say that implementations MUST NOT put more
> than one extension of the same type in a given extension block.  The
> peer has to validate received messages, but the local implementation has
> to know to not generate them, either.

There's also quite a bit of difference between:

- MUST NOT do X
- MUST NOT do X, MUST abort with Y if X is done.

As the second requires receiver to detect X, which can be hard. E.g.,
detecting arbitrary duplicated extension is definitely not trivial.
 
E.g., for duplicate extensions, my implementation only validates the
known extensions. As consequence, unknown extensions in offers can
appear multiple times without detection (e.g., two copies of extension
35 in ClientHello). It is done that way to limit resource usage:
Checking a small list of extensions is easy, checking 64k of those is
less so.

> >
> > - Servers MUST NOT accept the same ticket with the same binder
> > multiple
> >   times for 0-RTT (if any part of ClientHello covered by binder is
> >   different, one can assume binders are different). This holds even
> >   across servers (i.e., if server1 accepts 0-RTT with ticket X and
> >   binder Y, then server2 can not accept 0-RTT with ticket X and binder
> >   Y).
> >
> >
> > I assume that what you have in mind here is that the server would know
> > which tickets it was authoritative for anti-replay and would simply reject
> > 0-RTT if it wasn't authoritative? This seems like it would
> > significantly cut
> > down on mass replays, though it would of course still make
> > application-level
> > replay a problem.
> >
> 
> Right, this would bring replays down from the millions hypothesized for
> the weak time-based thing to more like tens, which is kind of in the
> regime that we are currently in with (at least some) application behavior.

Actually, even tens of replays at TLS level is quite dangerous,
especially if to different servers (bad information leaks via cache
attacks).

> > I'm happy to write this up as part of the first two techniques. I'd be 
> > interested in hearing from others in the WG what they think about:
> >
> 
> I think it's worth writing up the most-secure scheme(s) we know of, to
> give us some concrete text to digest and decide if we can live with.

However, every scheme that isn't the most-secure (tied 1st place) that
has been proposed so far is too insecure.

> > 1. Requiring it.
> > 2. Whether they still want to retain the stateless technique.
> >
> 
> If we think we can require it and have it actually stick, that seems
> like the safest plan.  The results of this discussion leave me uneasy
> with a scheme that permits millions of replays, even if there is not
> something concrete that I definitely object to.  As DKG (almost) said,
> "we're designing a security protocol, not an easy-to-implement
> protocol". 

There is major difference about how hard TLS 1.3 is to _implement_, and
how hard it is to _use_.

Most serious TLS 1.3 implementations will be written by experts.
Additionally, the protocol avoids using constructs that are almost
impossible to implement properly (e.g., good riddance TLS blockmode).

Whereas most applications using TLS will not be written by security
experts. And the protocols they implement are not designed for side-
channel resistance in implementations.

> Another crazy idea would be to just say that servers MUST limit the use
> of a single binder to at most 100 times, with the usual case being just
> once, to allow for alternative designs that have weaker distributed
> consensus requirements (but still describe these current two methods as
> examples of ways to do so).

You actually need strong distributed consensus about all accepted
0-RTT here.


-Ilari

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Benjamin Kaduk]

On 05/21/2017 05:47 PM, Eric Rescorla wrote:
>
>
> On Sat, May 20, 2017 at 6:16 AM, Ilari Liusvaara
> > wrote:
>
> On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote:
>  
>
> - Clients MUST NOT use the same ticket multiple times for 0-RTT.
>
>
> I don't understand the purpose of this requirement. As you note below,
> servers are ultimately responsible for enforcing it, and it's not clear to
> me why clients obeying it makes life easier for the server.
>

I think it's just an attempt to make clear what the client behavior
should be.  It's like when we say that implementations MUST NOT put more
than one extension of the same type in a given extension block.  The
peer has to validate received messages, but the local implementation has
to know to not generate them, either.

>  
>
> - Servers MAY accept the same ticket multiple times.
>
>
> This seems implicit.
>

It seems implicit to me, as well, though I'm not sure that there's harm
in saying it explicitly, particularly when reusing a ticket is a MUST
NOT in certain specific cases (0-RTT).

>  
>
> - Servers MUST NOT accept the same ticket with the same binder
> multiple
>   times for 0-RTT (if any part of ClientHello covered by binder is
>   different, one can assume binders are different). This holds even
>   across servers (i.e., if server1 accepts 0-RTT with ticket X and
>   binder Y, then server2 can not accept 0-RTT with ticket X and binder
>   Y).
>
>
> I assume that what you have in mind here is that the server would know
> which tickets it was authoritative for anti-replay and would simply reject
> 0-RTT if it wasn't authoritative? This seems like it would
> significantly cut
> down on mass replays, though it would of course still make
> application-level
> replay a problem.
>

Right, this would bring replays down from the millions hypothesized for
the weak time-based thing to more like tens, which is kind of in the
regime that we are currently in with (at least some) application behavior.

> I'm happy to write this up as part of the first two techniques. I'd be 
> interested in hearing from others in the WG what they think about:
>

I think it's worth writing up the most-secure scheme(s) we know of, to
give us some concrete text to digest and decide if we can live with.

> 1. Requiring it.
> 2. Whether they still want to retain the stateless technique.
>

If we think we can require it and have it actually stick, that seems
like the safest plan.  The results of this discussion leave me uneasy
with a scheme that permits millions of replays, even if there is not
something concrete that I definitely object to.  As DKG (almost) said,
"we're designing a security protocol, not an easy-to-implement
protocol".  I'm still concerned that if we put MUST it will be more RFC
6919 than 2119, though, even if clients and/or ssllabs try to grease
it.  So, if we require it, then the stateless technique is not needed
per se (but we still want the time limit so as to bound the size of a
strike register).  If we don't/can't require it, then I would say keep
the stateless technique but try to crank down the time window and
suggest that implementations rate-limit 0-RTT acceptance per domain to
try to get away from the billions of replay regime.

Another crazy idea would be to just say that servers MUST limit the use
of a single binder to at most 100 times, with the usual case being just
once, to allow for alternative designs that have weaker distributed
consensus requirements (but still describe these current two methods as
examples of ways to do so).

-Ben

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Benjamin Kaduk]

On 05/20/2017 04:33 AM, Ilari Liusvaara wrote:
>
> I meant what prevents the (say 10 second) windows from stacking up into
> (say 20 second windows) if 0-RTT is used on multiple hops (client-
> middlebox and middlebox-server)?
>
> One can not assume that the client has knowledge of any middlebox on
> the path (e.g. CDNs in HTTP are in general invisible to the client).
>

I think the attacker has to delay sending the client's 0-RTT to the
middlebox for the 10-second window if it wants to get the 20-second
delay overall (assuming the middlebox does at-most-once properly), at
which point the client would have a sense that something fishy might be
going on.  Though, that still doesn't give the client a hard bound on
the delay, I suppose.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Salz, Rich]

> Well it's a little more subtle then that; folks seem to acknowledge the 
> attacks
> but feel that their use-cases won't be affected.  I'm looking at you, Chrome,
> boring, Firefox :)

I've heard from two people that the "looking at you" phrase was not 
well-received.  I apologize to the list, and those whose feelings I hurt.  I 
look forward to seeing more detailed responses to Colm's posts soon. 

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Salz, Rich]

>I've seen a number of arguments here that essentially boil down to "We'd like 
>to keep it anyway, because it is so operationally convenient". Is that really 
>how this process works? Don't demonstrable real-world attacks deserve 
>deference?

Well it's a little more subtle then that; folks seem to acknowledge the attacks 
but feel that their use-cases won't be affected.  I'm looking at you, Chrome, 
boring, Firefox :)

Don't get discouraged. 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Security review of TLS1.3 0-RTT

[Benjamin Kaduk]

On 05/23/2017 01:07 PM, Colm MacCárthaigh wrote:
>
> I've seen a number of arguments here that essentially boil down to
> "We'd like to keep it anyway, because it is so operationally
> convenient". Is that really how this process works? Don't demonstrable
> real-world attacks deserve deference?

The process is more like "once the participants have gotten used to an
idea, it takes some time to digest countervailing reasoning when
potentially subtle issues are involved".  Without yet taking a position
myself, it seems like at least some folks are coming around to see your
position, and the dialogue should continue.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Tue, May 23, 2017 at 11:27 AM, Viktor Dukhovni 
wrote:

> Actually, nonces in DNScurve protect clients from replayed server
> responses (clients
> are stateful).  I see no explicit guidance to detect or refuse replays of
> client
> queries in DNScurve.  While servers could keep a nonce cache, in practice
> there
> are multiple servers and they don't share state (no "strike registers").
>

My apologies, you're right! I'll make sure to tease djb now. That's still
an insecure design (or at least a privacy defeating design) for the same
reasons as earlier. Though tinydns doesn't do RRL or Cyclic answers, so in
that coupled implementation it may be ok.

At one time we didn't think the kinds of side-channels present in TLS were
a big deal; the "it is not believed to be large enough to be exploitable" note
in section 6.2.3.2 of RFC5246 comes to mind. Here we risk repeating history.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Viktor Dukhovni]

> On May 23, 2017, at 2:07 PM, Colm MacCárthaigh  wrote:
> 
> That's not good for users, and seems like another very strong reason to make 
> it clear in the TLS draft that that it is not secure. FWIW; DNSCurve includes 
> nonces to avoid attacks like this: https://dnscurve.org/replays.html (which 
> means keeping state).

Actually, nonces in DNScurve protect clients from replayed server responses 
(clients
are stateful).  I see no explicit guidance to detect or refuse replays of client
queries in DNScurve.  While servers could keep a nonce cache, in practice there
are multiple servers and they don't share state (no "strike registers").

The replays discussed in the URL you provide are replays of stale, but still
within signature validity DNSSEC server responses.  Not replays of requests.

-- 
Viktor.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Tue, May 23, 2017 at 10:50 AM, Viktor Dukhovni 
wrote:

> The fix is to amend DNSpriv to require stateless (random rather
> than say round-robit) RRset rotation.  With random rotation, the
> next RRset order is independent of previous queries.
>

That's a good fix for that specific local problem. But next, consider a
different one; what if a DNS provider has q-tuple rate-limiting for DOS
attacks? That's not an unusual measure for large providers - even bind9 has
support for it. Well with stateless 0RTT I can replay the clients query
over and over until the rate-limiting trips; now I have a DOS attack *and*
a privacy-defeating attack; because the rate limit exposes what the query
was for.


> Secondly, even with the 0-RTT leak, while privacy against an active
> attacker might not be assured for all users, there is fact privacy
> for most users, especially against a purely passive adversary.
>

My reference here isn't really meant as a criticism of DNSPriv - we should
make DNS private and secure, that's awesome, and it's a small attack in the
overall context of DNS. It's meant like Christian said; it is really really
hard to make an application protocol idempotent and side-effect free and
very smart people are often wrong about assuming that they are. I see
at-most-once 0-RTT mitigation as essential to avoiding a lot of real world
security issues here, because of that difficulty.


> To the extent that DNSpriv over TLS happens at all, 0-RTT
> will be used for DNS, and will be used statelessly (allowing
> replays).


That's not good for users, and seems like another very strong reason to
make it clear in the TLS draft that that it is not secure. FWIW; DNSCurve
includes nonces to avoid attacks like this:
https://dnscurve.org/replays.html (which means keeping state).

Stateless mechanisms simply aren't secure. We wish they were; because it is
so attractive operationally - just as it would be nice if my MD5
accelerators were still useful. But they don't hold up. We've even seen
this before with DTLS; where replay tolerance opened up the window to
several cryptographic attacks. It's an all-round bad idea.

I've seen a number of arguments here that essentially boil down to "We'd
like to keep it anyway, because it is so operationally convenient". Is that
really how this process works? Don't demonstrable real-world attacks
deserve deference?

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Viktor Dukhovni]

> On May 23, 2017, at 12:52 PM, Christian Huitema  wrote:
> 
> Colm's point is that for many DNS servers, queries are not truly stateless. 
> The answer to a query for  records for example.net might vary over time, 
> or even query to query, for example to manage load balancing. Adversaries can 
> predict these variations. They can observe the state of the server before and 
> after replaying 0-RTT data. If they observed that the 0-RTT data caused the 
> answer to change, they can confirm that the 0-RTT data contained a request to 
> that server.

The fix is to amend DNSpriv to require stateless (random rather
than say round-robit) RRset rotation.  With random rotation, the
next RRset order is independent of previous queries.

Secondly, even with the 0-RTT leak, while privacy against an active
attacker might not be assured for all users, there is fact privacy
for most users, especially against a purely passive adversary.

DNS privacy is always an imperfect security mechanism because
the DNS query will often at in the provider request to the
authoritative servers leak the user's "subnet" in the clear,
typically in the form of the containing /20 CIDR block to aid
load-balacing CDNs.  Then after the response is received, the
client will send IP datagrams that further narrow the set of
potential domains.  Then in visiting a website there'll be
unencrypted SNI, or predictable patter of response sizes and
consequent retrieval of CSS/javascript/image resources that
fingerprint the request.

Cryptography and 0-RTT are far from the weakest link in the
chain here.  DNSpriv is necessarily imperfect incremental
security, and defeating traffic analysis is exceedingly
difficult.

To the extent that DNSpriv over TLS happens at all, 0-RTT
will be used for DNS, and will be used statelessly (allowing
replays).  If there are sufficiently cheap ways to improve
security (e.g. random RRset rotation) without sacrifing
performance, increasing latency or adding complexity, then
by all means promote their adoption.

-- 
Viktor.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Christian Huitema]

On 5/22/2017 7:53 PM, Colm MacCárthaigh wrote:
>
>
> On Mon, May 22, 2017 at 7:23 PM, Benjamin Kaduk  > wrote:
>
>
> Sorry for being daft, but a direct link to this additional
> side-channel would be helpful.
>
>
> I should have done it the first time.  Here it
> is: https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01277.html
>

Colm's point is that for many DNS servers, queries are not truly
stateless. The answer to a query for  records for example.net might
vary over time, or even query to query, for example to manage load
balancing. Adversaries can predict these variations. They can observe
the state of the server before and after replaying 0-RTT data. If they
observed that the 0-RTT data caused the answer to change, they can
confirm that the 0-RTT data contained a request to that server.

I take that as an example of the more generic statement, that it is
really difficult to guarantee that transactions are really stateless.
Some transactions are apparently stateless, because the operation in
theory only reads data from the server. But even these transactions can
change the state of the server in subtle ways, such as servers managing
load balancing. Another example would be web servers rotating
advertisements on the page, which also can be observed. If I get Colm's
point correctly, he asserts that this is a fairly general pattern, and
that only fools can assume that a given transaction is "stateless".

I take that as a strong argument for requiring "at most once"
functionality for 0-RTT data.

-- Christian Huitema

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Benjamin Kaduk]

On 05/22/2017 12:56 PM, Colm MacCárthaigh wrote:
>
>
> On Mon, May 22, 2017 at 10:46 AM, Christian Huitema
> > wrote
>
> Check DKG's analysis of 0-RTT for DNS over TLS:
> https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01276.html
> 
> .
> There is only one point of concern, a minor privacy leak if the
> DNS queries in the 0-RTT data can be replayed at intervals chosen
> by the attacker. The idea is to replay the data to a resolver, and
> then observe the queries going out to authoritative servers in
> clear text. The correlation can be used to find out what domain
> the client was attempting to resolve. The attack requires "chosen
> time" by the attacker, and thus will probably be mitigated by a
> caching system that prevents replays after a short interval.
>
>
>
> I have a reply to that too, linked at the bottom: there's actually a
> more trivial side-channel (due to non-idempotence) that hadn't been
> considered in the original analysis.
>

Sorry for being daft, but a direct link to this additional side-channel
would be helpful.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Mon, May 22, 2017 at 10:46 AM, Christian Huitema 
wrote
>
> Check DKG's analysis of 0-RTT for DNS over TLS: https://www.ietf.org/mail-
> archive/web/dns-privacy/current/msg01276.html. There is only one point of
> concern, a minor privacy leak if the DNS queries in the 0-RTT data can be
> replayed at intervals chosen by the attacker. The idea is to replay the
> data to a resolver, and then observe the queries going out to authoritative
> servers in clear text. The correlation can be used to find out what domain
> the client was attempting to resolve. The attack requires "chosen time" by
> the attacker, and thus will probably be mitigated by a caching system that
> prevents replays after a short interval.
>


I have a reply to that too, linked at the bottom: there's actually a more
trivial side-channel (due to non-idempotence) that hadn't been considered
in the original analysis.

I've yet to find /any/ example application where 0-RTT replay would
actually be side-channel free.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Christian Huitema]

On 5/22/2017 10:24 AM, Colm MacCárthaigh wrote:
>
>
> On Mon, May 22, 2017 at 10:12 AM, Kyle Nekritz  > wrote:
> ...
>
> Which mechanisms to use, and whether to enable 0-RTT in the first
> place (or PSK mode at all), should be decided considering the
> tradeoff between security/performance/implementation constraints,
> etc. In the case of DNS, most DNS security protocols (dnssec,
> etc.) do allow this kind of replay so I think it is a pretty
> reasonable tradeoff to consider.
>
>
>
> This same argument could be made for keeping MD5, or RC4.  DNSSEC is
> not concerned with secrecy. TLS is. This exact kind of replay would
> compromise the secrecy of the data being transported. 
>  
Check DKG's analysis of 0-RTT for DNS over TLS:
https://www.ietf.org/mail-archive/web/dns-privacy/current/msg01276.html.
There is only one point of concern, a minor privacy leak if the DNS
queries in the 0-RTT data can be replayed at intervals chosen by the
attacker. The idea is to replay the data to a resolver, and then observe
the queries going out to authoritative servers in clear text. The
correlation can be used to find out what domain the client was
attempting to resolve. The attack requires "chosen time" by the
attacker, and thus will probably be mitigated by a caching system that
prevents replays after a short interval.

-- Christian Huitema

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Mon, May 22, 2017 at 10:12 AM, Kyle Nekritz  wrote:

> The stateless technique certainly doesn’t solve all issues with replay.
> Neither do the other techniques, unless a fairly unrealistic (imo, in most
> use cases) retry strategy is used.
>


The stateless technique is insecure; plain and simple, and it is far more
easily exploited than issues that have caused us to deprecate cipher
suites. It should come out. It enables attacks that are materially
different from forced retries, such as cache probing and statistical
side-channel analysis.


> But the stateless technique is definitely an improvement over no
> anti-replay mechanism at all (for instance it reduces the possible number
> of rounds of a cache probing attack, assuming the cache TTL > replay
> window).
>

Today TLS has robust anti-replay; the comparison to "no anti-replay
mechanism at all" isn't relevant.



> Which mechanisms to use, and whether to enable 0-RTT in the first place
> (or PSK mode at all), should be decided considering the tradeoff between
> security/performance/implementation constraints, etc. In the case of DNS,
> most DNS security protocols (dnssec, etc.) do allow this kind of replay so
> I think it is a pretty reasonable tradeoff to consider.
>


This same argument could be made for keeping MD5, or RC4.  DNSSEC is not
concerned with secrecy. TLS is. This exact kind of replay would compromise
the secrecy of the data being transported.


> Additionally, I think the stateless technique is quite useful as a
> defense-in-depth mechanism.
>

It's tempting because it lowers the costs for implementors, but it's
absolutely not secure.  I seriously doubt that any application can be made
side-channel free in the manner that would be required to preserve secrecy.


> I highly doubt all deployments will end up correctly implementing a
> thorough anti-replay mechanism (whether accidentally or willfully).
>

This is why I think we should GREASE this and report (to users) any sites
that show any signs of replay tolerance.


> The stateless method is very cheap, and can be implemented entirely within
> a TLS library even in a distributed setup, only requiring access to an
> accurate clock. I’d much rather deployments without a robust and correct
> anti-replay mechanism break down to allowing replay over a number of
> seconds, rather than days (or longer).
>

I'd prefer if that were possible too, but it's not possible - it's
insecure.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Kyle Nekritz]

The stateless technique certainly doesn’t solve all issues with replay. Neither 
do the other techniques, unless a fairly unrealistic (imo, in most use cases) 
retry strategy is used. But the stateless technique is definitely an 
improvement over no anti-replay mechanism at all (for instance it reduces the 
possible number of rounds of a cache probing attack, assuming the cache TTL > 
replay window). Which mechanisms to use, and whether to enable 0-RTT in the 
first place (or PSK mode at all), should be decided considering the tradeoff 
between security/performance/implementation constraints, etc. In the case of 
DNS, most DNS security protocols (dnssec, etc.) do allow this kind of replay so 
I think it is a pretty reasonable tradeoff to consider.

Additionally, I think the stateless technique is quite useful as a 
defense-in-depth mechanism. I highly doubt all deployments will end up 
correctly implementing a thorough anti-replay mechanism (whether accidentally 
or willfully). The stateless method is very cheap, and can be implemented 
entirely within a TLS library even in a distributed setup, only requiring 
access to an accurate clock. I’d much rather deployments without a robust and 
correct anti-replay mechanism break down to allowing replay over a number of 
seconds, rather than days (or longer).

Kyle

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Colm MacCárthaigh
Sent: Sunday, May 21, 2017 10:29 PM
To: Eric Rescorla <e...@rtfm.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Security review of TLS1.3 0-RTT



On Sun, May 21, 2017 at 3:47 PM, Eric Rescorla 
<e...@rtfm.com<mailto:e...@rtfm.com>> wrote:
- Clients MUST NOT use the same ticket multiple times for 0-RTT.

I don't understand the purpose of this requirement. As you note below,
servers are ultimately responsible for enforcing it, and it's not clear to
me why clients obeying it makes life easier for the server.

I think clients should duplicate them sometimes, just to keep servers on their 
toes ;-) this is what we talked about maybe being a grease thing .. if at all.

- Servers MUST NOT accept the same ticket with the same binder multiple
  times for 0-RTT (if any part of ClientHello covered by binder is
  different, one can assume binders are different). This holds even
  across servers (i.e., if server1 accepts 0-RTT with ticket X and
  binder Y, then server2 can not accept 0-RTT with ticket X and binder
  Y).

I assume that what you have in mind here is that the server would know
which tickets it was authoritative for anti-replay and would simply reject
0-RTT if it wasn't authoritative? This seems like it would significantly cut
down on mass replays, though it would of course still make application-level
replay a problem.

I'm happy to write this up as part of the first two techniques. I'd be
interested in hearing from others in the WG what they think about:

1. Requiring it.
2. Whether they still want to retain the stateless technique.

I'm for requiring it, and for removing the stateless technique ... because it 
prevents the side-channel and DOS attacks and those seem like the most serious 
ones (and also, the new ones).

So far each case where we've thought "Actually stateless might be ok in this 
case" ... like the example of DNS ... turns out not to be safe when examined 
more closely (in DNSes case it would compromise privacy because caches could be 
probed).

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Christian Huitema]

On 5/21/2017 7:28 PM, Colm MacCárthaigh wrote:
>
>
> On Sun, May 21, 2017 at 3:47 PM, Eric Rescorla  > wrote:
>
>
>
> ...
>
> I'm happy to write this up as part of the first two techniques.
> I'd be 
> interested in hearing from others in the WG what they think about:
>
> 1. Requiring it.
> 2. Whether they still want to retain the stateless technique.
>
>
> I'm for requiring it, and for removing the stateless technique ...
> because it prevents the side-channel and DOS attacks and those seem
> like the most serious ones (and also, the new ones). 
>
> So far each case where we've thought "Actually stateless might be ok
> in this case" ... like the example of DNS ... turns out not to be safe
> when examined more closely (in DNSes case it would compromise privacy
> because caches could be probed). 

I would much rather see this specified within TLS than within the
application. Specifically, I would not like to see application making
statements that they can only use 0-RTT if the TLS software that they
use does implement "at most once" limitations on 0-RTT tickets. You
know, pretty much like those security sections that explain than a
careless application will be safe if it runs over IPSEC. Maybe with some
RFC 6919 language.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Sun, May 21, 2017 at 3:47 PM, Eric Rescorla  wrote:
>
> - Clients MUST NOT use the same ticket multiple times for 0-RTT.
>>
>
> I don't understand the purpose of this requirement. As you note below,
> servers are ultimately responsible for enforcing it, and it's not clear to
> me why clients obeying it makes life easier for the server.
>

I think clients should duplicate them sometimes, just to keep servers on
their toes ;-) this is what we talked about maybe being a grease thing ..
if at all.

- Servers MUST NOT accept the same ticket with the same binder multiple
>>   times for 0-RTT (if any part of ClientHello covered by binder is
>>   different, one can assume binders are different). This holds even
>>   across servers (i.e., if server1 accepts 0-RTT with ticket X and
>>   binder Y, then server2 can not accept 0-RTT with ticket X and binder
>>   Y).
>>
>
> I assume that what you have in mind here is that the server would know
> which tickets it was authoritative for anti-replay and would simply reject
> 0-RTT if it wasn't authoritative? This seems like it would significantly
> cut
> down on mass replays, though it would of course still make
> application-level
> replay a problem.
>
> I'm happy to write this up as part of the first two techniques. I'd be
> interested in hearing from others in the WG what they think about:
>
> 1. Requiring it.
> 2. Whether they still want to retain the stateless technique.
>

I'm for requiring it, and for removing the stateless technique ... because
it prevents the side-channel and DOS attacks and those seem like the most
serious ones (and also, the new ones).

So far each case where we've thought "Actually stateless might be ok in
this case" ... like the example of DNS ... turns out not to be safe when
examined more closely (in DNSes case it would compromise privacy because
caches could be probed).

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Eric Rescorla]

On Sat, May 20, 2017 at 6:16 AM, Ilari Liusvaara 
wrote:

> On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote:
>
> >
> > Some protection is necessary; but it isn't too hard - a single-use
> session
> > cache, or a strike register, do protect against the side-channel and DOS
> > problems. Combined with a "fail closed" strategy and tickets that are
> > scoped to clusters or servers, these techniques do hard-stop the literal
> > 0-RTT replays, and they are practical. Many of us run systems like that
> > already.
>
> As requirements:
>
> - Clients SHOULD NOT use the same ticket multiple times.
>

This is already in the document.



> - Clients MUST NOT use the same ticket multiple times for 0-RTT.
>

I don't understand the purpose of this requirement. As you note below,
servers are ultimately responsible for enforcing it, and it's not clear to
me why clients obeying it makes life easier for the server.



> - Servers MAY accept the same ticket multiple times.
>

This seems implicit.



> - Servers MUST NOT accept the same ticket with the same binder multiple
>   times for 0-RTT (if any part of ClientHello covered by binder is
>   different, one can assume binders are different). This holds even
>   across servers (i.e., if server1 accepts 0-RTT with ticket X and
>   binder Y, then server2 can not accept 0-RTT with ticket X and binder
>   Y).
>

I assume that what you have in mind here is that the server would know
which tickets it was authoritative for anti-replay and would simply reject
0-RTT if it wasn't authoritative? This seems like it would significantly cut
down on mass replays, though it would of course still make application-level
replay a problem.

I'm happy to write this up as part of the first two techniques. I'd be
interested in hearing from others in the WG what they think about:

1. Requiring it.
2. Whether they still want to retain the stateless technique.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Ilari Liusvaara]

On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote:

> 
> Some protection is necessary; but it isn't too hard - a single-use session
> cache, or a strike register, do protect against the side-channel and DOS
> problems. Combined with a "fail closed" strategy and tickets that are
> scoped to clusters or servers, these techniques do hard-stop the literal
> 0-RTT replays, and they are practical. Many of us run systems like that
> already.

As requirements:

- Clients SHOULD NOT use the same ticket multiple times.
- Clients MUST NOT use the same ticket multiple times for 0-RTT.
- Servers MAY accept the same ticket multiple times.
- Servers MUST NOT accept the same ticket with the same binder multiple
  times for 0-RTT (if any part of ClientHello covered by binder is
  different, one can assume binders are different). This holds even
  across servers (i.e., if server1 accepts 0-RTT with ticket X and
  binder Y, then server2 can not accept 0-RTT with ticket X and binder
  Y).

The "with the same binder" requirement is to deal with the following:

1) Bad client sends 0-RTT with ticket X and in-window age age1.
2) Some days pass...
3) Bad client sends 0-RTT with ticket X and in-window age age2.

Without the "with the same binder", that would mean the server MUST
reject the 0-RTT for 3), which would mean keeping state for days,
which leads to excessive resource usage.

With the "with same binder", the server can time out the state for
1) as soon as the age1 is out-of-window. And then it MAY accept
0-RTT for 3). This will not lead into mass replay possibility for
either 1) nor 3).

The part of assuming binders different if any part covered is
different comes from strong hash requirement TLS 1.3 has.


?

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Ilari Liusvaara]

On Fri, May 19, 2017 at 01:10:29PM -0700, Colm MacCárthaigh wrote:
> On Fri, May 19, 2017 at 11:40 AM, Ilari Liusvaara 
> wrote:
> 
> > > * In order to fully reason about when that message may later get
> > received,
> > > there needs to be an agreed upon time-cap for 0-RTT receipt. Agreed by
> > all
> > > potential middle-boxes in the pipe that may be using 0-RTT.
> >
> > Isn't that potentially multi-party problem if middleboxes are involved?
> >
> 
> Yes; but if we can agree on a hard maximum time-window for the 0RTT
> section, and all of the parties agree, it's possible for a careful client
> to negotiate its way around it. Even if it's 10 seconds, this still has
> some value I think.

I meant what prevents the (say 10 second) windows from stacking up into
(say 20 second windows) if 0-RTT is used on multiple hops (client-
middlebox and middlebox-server)?

One can not assume that the client has knowledge of any middlebox on
the path (e.g. CDNs in HTTP are in general invisible to the client).


-Ilari

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Eric Rescorla]

On Fri, May 19, 2017 at 4:49 PM, David Benjamin 
wrote:

> Seeing as this utterly ridiculous ticket_age_add thing is partially my
> fault, I suppose I should respond:
>
> On Fri, May 19, 2017 at 4:10 PM Colm MacCárthaigh 
> wrote:
>
>> > And then separate to all of the above, and lower priority:
>>> >
>>> > * There's a contradiction between the obfuscated ticket age add
>>> parameter
>>> > and the desire to use tickets multiple times in other (non-0RTT)
>>> cases. We
>>> > can't do one without defeating the point of the other. Either remove
>>> the
>>> > obfuscation because it is misleading, or move it into an encrypted
>>> message
>>> > so that it is robust.
>>>
>>> The purpose of obfustication is not to hide sibling sessions. The
>>> client already blows its cover by using the same session ID twice. The
>>> purpose of obfustication is to hide the parent session.
>>
>>
>>> Are you talking about attackers being able to determine the rate of
>>> client clock?
>>>
>>
>> Right now if a ticket is used multiple times, then the ticket age can be
>> derived (trivial cryptanalysis due to re-using the same obfuscated offset,
>> and because the progression of time between the ticket uses is public);
>> that means the parent session can be identified. So the point is defeated.
>>
>
> Could you expand on your cryptanalysis? I don't believe this is actually
> leaked. It's addition mod 2^32, not XOR, which means you effectively
> randomize the parent starting time. (It was initially XOR, and then shortly 
> changed
> to addition
> .)
> Consider:
>
> initial connection at time t1, issues a ticket with ticket_age_add = x.
> Let t1' = t1 - x.
> Resumption 1 at time t2, offers t1's ticket. The attacker learns t2 - t1 +
> x = t2 - t1'.
> Resumption 2 (or HelloRetryRequest) at time t3, offers t1's ticket. The
> attacker learns t3 - t1 + x = t3 - t1'.
>
> x is uniformly distributed over [0, 2^32), so t1' = t1 - x is as well.
> This is a one-time pad on t1, correctly used only once. x is only ever used
> to encrypt one timestamp, t1.
>
> Of course, the attacker can correlate t2 and t3 by subtracting the two
> public values and checking against the public difference between
> connections they observe. But the ticket's already leaked anyway.
>
>
>> Either the one-time-pad can be used just one time (which means the ticket
>> can be used just once) or we should move it to an encrypted message. Or
>> just get rid of it and not be so misleading. But the current state is
>> weird, to say the least.
>>
>
> I believe stuffing something into an AEAD was proposed and then rejected
> by the cryptographers for some reason? You'd have to ask other folks for
> details. I just recall being told that was a previous rejected proposal.
> Accordingly, I suggested the dumbest thing that could possibly work,
> intending it be so dumb that it could not possibly have consequences beyond
> patching that correlation hole. :-)
>

What was rejected was actually having the stuffed Finished be an
AEAD-encrypted block
containing stuff like the ticket_age. We could certainly derive a new key
and AEAD it if
we wanted to, that just seemed like a lot more work than I think people
wanted to do.

-Ekr


>
>
> David
>
> ___
> 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] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Fri, May 19, 2017 at 1:58 PM, Viktor Dukhovni 
wrote:
>
> +1.  The additive obfuscation leaks nothing that is not already leaked
> just by sending the tickets.
>

You're both right, that does work out. I was thinking my balanced equations
stupidly and solving for x while forgetting that t1' is secret.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Viktor Dukhovni]

> On May 19, 2017, at 4:49 PM, David Benjamin  wrote:
> 
> Could you expand on your cryptanalysis? I don't believe this is actually 
> leaked. It's addition mod 2^32, not XOR, which means you effectively 
> randomize the parent starting time. (It was initially XOR, and then shortly 
> changed to addition.) Consider:
> 
> initial connection at time t1, issues a ticket with ticket_age_add = x. Let 
> t1' = t1 - x.
> Resumption 1 at time t2, offers t1's ticket. The attacker learns t2 - t1 + x 
> = t2 - t1'.
> Resumption 2 (or HelloRetryRequest) at time t3, offers t1's ticket. The 
> attacker learns t3 - t1 + x = t3 - t1'.
> 
> x is uniformly distributed over [0, 2^32), so t1' = t1 - x is as well. This 
> is a one-time pad on t1, correctly used only once. x is only ever used to 
> encrypt one timestamp, t1.
> 
> Of course, the attacker can correlate t2 and t3 by subtracting the two public 
> values and checking against the public difference between connections they 
> observe. But the ticket's already leaked anyway.

+1.  The additive obfuscation leaks nothing that is not already leaked just by 
sending the tickets.

-- 
Viktor.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[David Benjamin]

Seeing as this utterly ridiculous ticket_age_add thing is partially my
fault, I suppose I should respond:

On Fri, May 19, 2017 at 4:10 PM Colm MacCárthaigh 
wrote:

> > And then separate to all of the above, and lower priority:
>> >
>> > * There's a contradiction between the obfuscated ticket age add
>> parameter
>> > and the desire to use tickets multiple times in other (non-0RTT) cases.
>> We
>> > can't do one without defeating the point of the other. Either remove the
>> > obfuscation because it is misleading, or move it into an encrypted
>> message
>> > so that it is robust.
>>
>> The purpose of obfustication is not to hide sibling sessions. The
>> client already blows its cover by using the same session ID twice. The
>> purpose of obfustication is to hide the parent session.
>
>
>> Are you talking about attackers being able to determine the rate of
>> client clock?
>>
>
> Right now if a ticket is used multiple times, then the ticket age can be
> derived (trivial cryptanalysis due to re-using the same obfuscated offset,
> and because the progression of time between the ticket uses is public);
> that means the parent session can be identified. So the point is defeated.
>

Could you expand on your cryptanalysis? I don't believe this is actually
leaked. It's addition mod 2^32, not XOR, which means you effectively
randomize the parent starting time. (It was initially XOR, and then
shortly changed
to addition
.)
Consider:

initial connection at time t1, issues a ticket with ticket_age_add = x. Let
t1' = t1 - x.
Resumption 1 at time t2, offers t1's ticket. The attacker learns t2 - t1 +
x = t2 - t1'.
Resumption 2 (or HelloRetryRequest) at time t3, offers t1's ticket. The
attacker learns t3 - t1 + x = t3 - t1'.

x is uniformly distributed over [0, 2^32), so t1' = t1 - x is as well. This
is a one-time pad on t1, correctly used only once. x is only ever used to
encrypt one timestamp, t1.

Of course, the attacker can correlate t2 and t3 by subtracting the two
public values and checking against the public difference between
connections they observe. But the ticket's already leaked anyway.


> Either the one-time-pad can be used just one time (which means the ticket
> can be used just once) or we should move it to an encrypted message. Or
> just get rid of it and not be so misleading. But the current state is
> weird, to say the least.
>

I believe stuffing something into an AEAD was proposed and then rejected by
the cryptographers for some reason? You'd have to ask other folks for
details. I just recall being told that was a previous rejected proposal.
Accordingly, I suggested the dumbest thing that could possibly work,
intending it be so dumb that it could not possibly have consequences beyond
patching that correlation hole. :-)

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Fri, May 19, 2017 at 11:44 AM, Eric Rescorla  wrote:

> Yup. There are no known reasons that prevent at-most-once 0-RTT delivery,
>
>> even with distributed servers for the origin.
>>
>
> I don't disagree with that necessarily, but if the client responds by
> retransmitting
> in 1-RTT, then you don't have overall at-most-once.
>

Obviously this is fine for browsers; retry's make sense there anyway, and
so if we prevent mass-replay then there are no new attacks like the
side-channels and DOSes.

If a client needs to be more careful; with a hard-time limit on ticket use,
it can actually reason its way to at-most-once. It needs to wait out the
time limit, then do a read; to see if the original attempt succeeded or
not, and only then retry. That's a fairly common mode in eventually
consistent systems, loss-tolerant protocols and distributed consensus
protocols. For example some S3 clients and PAXOS systems work like this.

Of course it's very inconvenient to have to sometimes block for 10 seconds
(or whatever we pick), in return for a speed up of maybe as much as ~200ms
in the "ordinary" case; but it's the kind of trade-off that an
instrumentation system might make; like an industrial controller - where
day-to-day system liveness is a massive optimization benefit and the
occasional interruption is no big deal.

Super esoteric, and maybe we shouldn't even think too much about it, but I
bring it out because that construction is the only one I've found that gets
to at-most-once delivery; and it highlights that the existing system
explicitly doesn't and might just be needless complexity (the multiple
streams signaling).

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Fri, May 19, 2017 at 11:40 AM, Ilari Liusvaara 
wrote:

> > * In order to fully reason about when that message may later get
> received,
> > there needs to be an agreed upon time-cap for 0-RTT receipt. Agreed by
> all
> > potential middle-boxes in the pipe that may be using 0-RTT.
>
> Isn't that potentially multi-party problem if middleboxes are involved?
>

Yes; but if we can agree on a hard maximum time-window for the 0RTT
section, and all of the parties agree, it's possible for a careful client
to negotiate its way around it. Even if it's 10 seconds, this still has
some value I think.


> > And then separate to all of the above, and lower priority:
> >
> > * There's a contradiction between the obfuscated ticket age add parameter
> > and the desire to use tickets multiple times in other (non-0RTT) cases.
> We
> > can't do one without defeating the point of the other. Either remove the
> > obfuscation because it is misleading, or move it into an encrypted
> message
> > so that it is robust.
>
> The purpose of obfustication is not to hide sibling sessions. The
> client already blows its cover by using the same session ID twice. The
> purpose of obfustication is to hide the parent session.


> Are you talking about attackers being able to determine the rate of
> client clock?
>

Right now if a ticket is used multiple times, then the ticket age can be
derived (trivial cryptanalysis due to re-using the same obfuscated offset,
and because the progression of time between the ticket uses is public);
that means the parent session can be identified. So the point is defeated.

Either the one-time-pad can be used just one time (which means the ticket
can be used just once) or we should move it to an encrypted message. Or
just get rid of it and not be so misleading. But the current state is
weird, to say the least.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Eric Rescorla]

On Fri, May 19, 2017 at 2:40 PM, Ilari Liusvaara 
wrote:

> On Fri, May 19, 2017 at 09:59:57AM -0700, Colm MacCárthaigh wrote:
> > On Fri, May 19, 2017 at 2:53 AM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> > >
> > > - Even if once-per-server or once-per-cluster replay detection limits
> > >   the number of replays to few hundred to few thoursand at maximum,
> > >   where the low-level crypto side channels are much less of a threat,
> > >   cache attacks can be used to break security (in fact, not sending a
> > >   mad burst of data to any one server is useful for carrying out
> these).
> > >
> >
> > I wouldn't be too fatalistic about it. The speed of light is too slow for
> > human interaction, and 0-RTT is an important and awesome feature that we
> > should make safe and near universal.
> >
> > Some protection is necessary; but it isn't too hard - a single-use
> session
> > cache, or a strike register, do protect against the side-channel and DOS
> > problems. Combined with a "fail closed" strategy and tickets that are
> > scoped to clusters or servers, these techniques do hard-stop the literal
> > 0-RTT replays, and they are practical. Many of us run systems like that
> > already.
>
> Yup. There are no known reasons that prevent at-most-once 0-RTT delivery,
> even with distributed servers for the origin.
>

I don't disagree with that necessarily, but if the client responds by
retransmitting
in 1-RTT, then you don't have overall at-most-once.

-Ekr



>
> Of course, this impiles that there is some small-enough spatial scope
> for 0-RTT, so servers in scope can reach global consistency in acceptable
> time (which also sets the server timeout!)
>
> Latencies within a single datacenter should be pretty low, and routing
> should be pretty sticky between datacenters.
>
> > Here's all I think we need to fix all of this though, in order of
> priority:
> >
> > For relatively "Normal" clients (e.g. Browsers):
> >
> > * Servers supporting 0-RTT need to robustly prevent replay of literal
> 0-RTT
> > sections. No time-based mitigation, which simply doesn't work. This is
> the
> > "cost" of doing 0-RTT.
> > * Clients should be the real arbiter of what to use 0-RTT; e.g. never use
> > for POST, etc. This could bear some emphasis. It's important because
> > middle-boxes exist.
>
> Yeah, for clients that are as careless with HTTP as browsers, sending
> POSTs in 0-RTT data is very bad idea.
>
> > For careful clients, think about something implementing a transaction
> over
> > TLS:
> >
> > * If a 0-RTT section is sent but does not result in a successful receipt,
> > that failure needs to be signaled to the client.
>
> This is already required in order to implement HTTP semantics. E.g. so
> that if 0-RTT section contains POST request, the HTTP library can signal
> its client "failed: connection to server lost before reply was
> received" (and retry GETs, PUTs and DEETEs).
>
> > * In order to fully reason about when that message may later get
> received,
> > there needs to be an agreed upon time-cap for 0-RTT receipt. Agreed by
> all
> > potential middle-boxes in the pipe that may be using 0-RTT.
>
> Isn't that potentially multi-party problem if middleboxes are involved?
>
>
> > And then separate to all of the above, and lower priority:
> >
> > * There's a contradiction between the obfuscated ticket age add parameter
> > and the desire to use tickets multiple times in other (non-0RTT) cases.
> We
> > can't do one without defeating the point of the other. Either remove the
> > obfuscation because it is misleading, or move it into an encrypted
> message
> > so that it is robust.
>
> The purpose of obfustication is not to hide sibling sessions. The
> client already blows its cover by using the same session ID twice. The
> purpose of obfustication is to hide the parent session.
>
> Are you talking about attackers being able to determine the rate of
> client clock?
>
>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Fri, May 19, 2017 at 2:53 AM, Ilari Liusvaara 
wrote:
>
> To me, that reads as gross understatement about the dangers involved in
> 0-RTT:
>
> - The side channel attacks with millions or billions of replays are hard
>   to protect against. This is if the side channels are in TLS library.
>   If not, protecting against that sort of side channels becomes
>   virtually impossible.

- Furthermore, with that kind of replay volume, protecting against DoS
>   attacks is virtually impossible.


> - Even if once-per-server or once-per-cluster replay detection limits
>   the number of replays to few hundred to few thoursand at maximum,
>   where the low-level crypto side channels are much less of a threat,
>   cache attacks can be used to break security (in fact, not sending a
>   mad burst of data to any one server is useful for carrying out these).
>

I wouldn't be too fatalistic about it. The speed of light is too slow for
human interaction, and 0-RTT is an important and awesome feature that we
should make safe and near universal.

Some protection is necessary; but it isn't too hard - a single-use session
cache, or a strike register, do protect against the side-channel and DOS
problems. Combined with a "fail closed" strategy and tickets that are
scoped to clusters or servers, these techniques do hard-stop the literal
0-RTT replays, and they are practical. Many of us run systems like that
already.


> Also, the kind of thing going on here seems exactly how I would imagine
> the past very bad decisions from TLS WG, that were known to be insecure
> at the time of specification and where then successfully attacked later,
> played out. However, I have not read those discussions from the ML
> archives.
>

In this case, I think people see the trade-offs differently and that's ok.
There's a sense that the risks or cost are worth it. After all, you can
mitigate a lot of the risk if you have a team of experts on standby who
manually mitigate these kinds of attacks, or more advanced automated
response systems. And many big providers do have both of these.

What concerns me most is that the 0-RTT interactions here are formalizable
and that the messaging interactions can be modeled in TLA+, F*, etc ... but
that hasn't been done as it has with the rest of the TLS1.3 state machine.

My TLA+ simple model convinced me that what's in the draft doesn't actually
work; there's nothing in the messages that allows a server to de-dupe, I
wrote up a simple 3-message example of this earlier in the thread, and it
seems to hold to the breaking the "X-" header trick that one provider came
up with.  That already in this draft deployment phase, that can advanced,
knowledgable, provider's attempt at a mitigation can be shown to be broken
should be cause for alarm. It's not a safe set-up.

Here's all I think we need to fix all of this though, in order of priority:

For relatively "Normal" clients (e.g. Browsers):

* Servers supporting 0-RTT need to robustly prevent replay of literal 0-RTT
sections. No time-based mitigation, which simply doesn't work. This is the
"cost" of doing 0-RTT.
* Clients should be the real arbiter of what to use 0-RTT; e.g. never use
for POST, etc. This could bear some emphasis. It's important because
middle-boxes exist.

For careful clients, think about something implementing a transaction over
TLS:

* If a 0-RTT section is sent but does not result in a successful receipt,
that failure needs to be signaled to the client.
* In order to fully reason about when that message may later get received,
there needs to be an agreed upon time-cap for 0-RTT receipt. Agreed by all
potential middle-boxes in the pipe that may be using 0-RTT.

And then separate to all of the above, and lower priority:

* There's a contradiction between the obfuscated ticket age add parameter
and the desire to use tickets multiple times in other (non-0RTT) cases. We
can't do one without defeating the point of the other. Either remove the
obfuscation because it is misleading, or move it into an encrypted message
so that it is robust.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Ilari Liusvaara]

On Tue, May 16, 2017 at 05:39:55PM -0700, Eric Rescorla wrote:
> On Thu, May 4, 2017 at 2:13 PM, Eric Rescorla  wrote:
> 
> > As promised:
> > https://github.com/tlswg/tls13-spec/pull/1005
> >
> > Note: I may have to do a little post-landing cleanup, but I wanted to get
> > people's senses of the text ASAP.
> >
> 
> Thanks for everyone's comments. I've updated the text to address many of
> them and
> made comments in Github where I decided not to do so. Can those who have
> read
> the previous version please take a look?

To me, that reads as gross understatement about the dangers involved in
0-RTT:

- The side channel attacks with millions or billions of replays are hard
  to protect against. This is if the side channels are in TLS library.
  If not, protecting against that sort of side channels becomes
  virtually impossible.
- Furthermore, with that kind of replay volume, protecting against DoS
  attacks is virtually impossible.
- Even if once-per-server or once-per-cluster replay detection limits
  the number of replays to few hundred to few thoursand at maximum,
  where the low-level crypto side channels are much less of a threat,
  cache attacks can be used to break security (in fact, not sending a
  mad burst of data to any one server is useful for carrying out these).
- 0-RTT Exporters are severly broken unless servers do strict anti-
  replay.

(I left unordered replay out, because I don't see how that is
actually created by 0-RTT, as opposed to just being made easier).

There are no inherent problems in 0-RTT that I know of that would
prevent sending even non-idempotent things like HTTP POSTs over it
(however, failure rates are increased if you do). However, as
currently described, I would not think 0-RTT is safe for anything
except very boring things like protocol banners. I also do not
consider it safe enough to implement in anything that actually
considers security.


Also, on 0-RTT enable/disable: I would imagine that some browsers at
first might have an option to disable 0-RTT. However, I expect that
over time it will get removed (like what happened with the session
ticket support in Firefox), so when serious problem is discovered, there
is no option to disable the vulernable feature at all (like happened
with tickets in TLS 1.0-1.2) or the disable is far too wide (e.g.
disabling whole TLS 1.3 in order to disable 0-RTT).



Also, the kind of thing going on here seems exactly how I would imagine
the past very bad decisions from TLS WG, that were known to be insecure
at the time of specification and where then successfully attacked later,
played out. However, I have not read those discussions from the ML
archives.



-Ilari

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Eric Rescorla]

On Thu, May 4, 2017 at 2:13 PM, Eric Rescorla  wrote:

> As promised:
> https://github.com/tlswg/tls13-spec/pull/1005
>
> Note: I may have to do a little post-landing cleanup, but I wanted to get
> people's senses of the text ASAP.
>

Thanks for everyone's comments. I've updated the text to address many of
them and
made comments in Github where I decided not to do so. Can those who have
read
the previous version please take a look?

I'd also like to merge PR#998. I haven't heard any real complaints about it
and it's
an improvement in any case. I'll await the chairs on that, though.

-Ekr



Comments welcome.
> -Ekr
>
>
> On Wed, May 3, 2017 at 8:21 PM, Eric Rescorla  wrote:
>
>>
>>
>> On Wed, May 3, 2017 at 8:20 PM, Colm MacCárthaigh 
>> wrote:
>>
>>>
>>>
>>> On Wed, May 3, 2017 at 8:13 PM, Eric Rescorla  wrote:
>>>
 I made some proposals yesterday
 (https://www.ietf.org/mail-archive/web/tls/current/msg23088.html).

 Specifically:
 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
 both session-cache and strike register styles and the merits of each.

 2. Document 0-RTT greasing in draft-ietf-tls-grease

 3. Adopt PR#448 (or some variant) so that session-id style
 implementations
 provide PFS.

 4. I would add to this that we recommend that proxy/CDN implementations
 signal which data is 0-RTT and which is 1-RTT to the back-end (this was
 in
 Colm's original message).

>>>
>>> This all sounds great to me. I'm not sure that we need (4.) if we have
>>> (1.).  I think with (1.) - recombobulating to a single stream might even be
>>> best overall, to reduce application complexity, and it seems to be what
>>> most implementors are actually doing.
>>>
>>> I know that leaves the DKG attack, but from a client and servers
>>> perspective that attack is basically identical to a server timeout, and
>>> it's something that systems likely have some fault tolerance around. It's
>>> not /new/ broken-ness.
>>>
>>
>> Heh. Always happy to do less writing.
>>
>> Thanks,
>> -Ekr
>>
>>
>>>
>>>
 Based on Colm's response, I think these largely hits the points he made
 in his original message.

 There's already a PR for #3 and I'll have PRs for #1 and #4 tomorrow.
 What would be most helpful to me as Editor would be if people could
 review
 these PRs and/or suggest other specific changes that we should make
 to the document.

>>>
>>> Will do! Many thanks.
>>>
>>> --
>>> Colm
>>>
>>
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Security review of TLS1.3 0-RTT

[Viktor Dukhovni]

> On May 6, 2017, at 8:51 PM, Eric Rescorla  wrote:
> 
> Yes, they can. But doing so leaks a unique identifier, which can be used
> to link sessions. When I look at the privacy implications as well as the
> replay attacks, there is real value in using a resume ticket only once.
> 
> Agreed.  Also, I think that's Ben Kaduk you're quoting :)

Agreed, on the general case, but a reminder that not all applications
benefit from such "privacy".  A sending SMTP MTA has a fixed public
IP address, and even sends a fixed fixed SMTP "HELO" name in the clear
before STARTTLS.  It might of course also send SNI in the clear, ...
and will typically perform cleartext DNS queries that identify the
peer.  There is exceedingly little opportunity or desire to hide client
and server host names.  So some applications will reuse session tickets
(while avoiding 0-RTT).

-- 
Viktor.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Eric Rescorla]

On Sat, May 6, 2017 at 5:35 PM, Christian Huitema 
wrote:

>
>
> On 5/4/2017 10:12 PM, Eric Rescorla wrote:
> >
> > Obligatory note that if clients are forbidden from reusing a single
> > PSK for multiple 0-RTT, they can still use it for 1-RTT.
>
> Yes, they can. But doing so leaks a unique identifier, which can be used
> to link sessions. When I look at the privacy implications as well as the
> replay attacks, there is real value in using a resume ticket only once.
>

Agreed.  Also, I think that's Ben Kaduk you're quoting :)

-Ekr


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

Re: [TLS] Security review of TLS1.3 0-RTT

[Christian Huitema]

On 5/4/2017 10:12 PM, Eric Rescorla wrote:
>
> Obligatory note that if clients are forbidden from reusing a single
> PSK for multiple 0-RTT, they can still use it for 1-RTT.

Yes, they can. But doing so leaks a unique identifier, which can be used
to link sessions. When I look at the privacy implications as well as the
replay attacks, there is real value in using a resume ticket only once.

-- Christian Huitema



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

Re: [TLS] Security review of TLS1.3 0-RTT

[Nico Williams]

On Fri, May 05, 2017 at 12:07:09AM -0500, Benjamin Kaduk wrote:
> On 05/03/2017 09:33 PM, Blumenthal, Uri - 0553 - MITLL wrote:
> > P.S. Care to name (another :) one security-related protocol that
> > doesn't provide replay protection?
> 
> Some of the earlier uses of Kerberos are subject to replay (hence
> kerberos implementations can end up providing replay caches to try and
> help, which are not perfect and slow to boot).  More modern exchanges
> that use GSS acceptor subkeys are not subject to replay, though.

We might be getting far afield now, but if you're not using "mutual
auth" then GSS/Kerberos will look a lot like TLS 1.3 0-rtt.  GSS apps
that want that need to be careful, just as TLS 1.3 0-rtt apps.

Also, even for the 1-rtt case, GSS/Kerberos supports early (0-rtt) data.

Nico
-- 

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Ilari Liusvaara]

On Thu, May 04, 2017 at 10:12:34PM -0700, Eric Rescorla wrote:
> On Thu, May 4, 2017 at 10:07 PM, Benjamin Kaduk  wrote:
> 
> >
> > That seems like an inconsistent position to take (don't do this, but if
> > you ignore me, do this in this fashion).  Advising application profiles to
> > consider one of those things might be better.
> >
> 
> That's just incompetent writing by me, I guess.
> 
> For 2, I meant "If there is an application profile allowing 0-RTT, but it
> doesn't say you don't
> need mitigations, then you MUST..."

I think the two methods (use-once session database and strike register)
should additionally be formulated so that those have sufficient
atomicity to eliminate 0-RTT replay.

This of course impiles that the scope of 0-RTT is sufficiently small
for synchronization to propagate quickly enough (this probably limits
the scope to a datacenter, but this should not be a problem in
practice).

Then clients should also be restricted to using the same ticket just
once for 0-RTT (absent a application profile), with due atomicity.

Also, I think use of 0-RTT exporters should require atomic session
database or strike register, no matter what application profile says,
as otherwise 0-RTT exporters become insecure.


Obviously, these 0-RTT safeguards don't need to apply to 1-RTT using a
dynamic PSK. That can be reused (obiviously at cost of linkability).


Also, a trick: The first binder makes a good identifier for the
ClientHello for purposes of 0-RTT replay detection.


-Ilari

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Eric Rescorla]

On Thu, May 4, 2017 at 10:07 PM, Benjamin Kaduk  wrote:

> Trying to consolidate various things into a single mail...
>
> On 05/04/2017 04:37 PM, Eric Rescorla wrote:
>
> In the PR I just posted, I spent most of my time describing the
> mechanisms and used a SHOULD-level requirement to do one of the mechanisms.
> I think there's a bunch of room to wordsmith the requirement. Perhaps we
> say:
>
> - You can't do 0-RTT without an application profile
> - Absent the application profile saying otherwise you SHOULD/MUST do one
> of these mitigations?
>
>
>
> That seems like an inconsistent position to take (don't do this, but if
> you ignore me, do this in this fashion).  Advising application profiles to
> consider one of those things might be better.
>

That's just incompetent writing by me, I guess.

For 2, I meant "If there is an application profile allowing 0-RTT, but it
doesn't say you don't
need mitigations, then you MUST..."


-Ekr


>
>
>
> On 05/04/2017 04:27 PM, Kyle Nekritz wrote:
>
> 2) Preventing clients from sending 0-RTT data multiple times (on separate
> connections) using the same PSK (for forward secrecy reasons)
>
>
>
> I think this should be allowed. Otherwise, clients will not be able to
> retry 0-RTT requests that fail due to an unknown network error prior to
> receiving a NST (if they are out of cached PSKs). I’d expect the need for
> these retries to be larger with 0-RTT data, particularly when 0-RTT data is
> sent without even a transport roundtrip (in the case of TFO or QUIC).
> Servers are definitely not required to accept multiple 0-RTT connections
> using the same PSK, but I don’t think clients should be banned from
> attempting.
>
>
> Obligatory note that if clients are forbidden from reusing a single PSK
> for multiple 0-RTT, they can still use it for 1-RTT.
>
>
>
> On 05/04/2017 03:24 PM, Colm MacCárthaigh wrote:
>
> On Thu, May 4, 2017 at 12:12 PM, Erik Nygren  wrote:
>
>> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla  wrote:
>>
>>>
>>> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
>>> both session-cache and strike register styles and the merits of each.
>>>
>>
>> I don't believe this is technically viable for the large-scale server
>> operators most interested in 0-RTT.
>>
>
> I think it is (and work at one of the biggest) ... but if even it weren't,
> that would just imply that we can't have 0-RTT at all, not that it's ok to
> ship an insecure version.
>
>
> I would be okay with that being the case ... but I don't think that's
> actually the case.  Some people are going to do 0-RTT in one form or
> another, whether or not we specify it here.  I'd rather have something
> well-specified that can be used correctly in some cases and is
> unfortunately used in more cases than that, then a 
> less-well-documented-and-analyzed
> thing used in those same questionable cases.
>
>
> On 05/03/2017 09:33 PM, Blumenthal, Uri - 0553 - MITLL wrote:
>
> P.S. Care to name (another :) one security-related protocol that doesn't
> provide replay protection?
>
>
> Some of the earlier uses of Kerberos are subject to replay (hence kerberos
> implementations can end up providing replay caches to try and help, which
> are not perfect and slow to boot).  More modern exchanges that use GSS
> acceptor subkeys are not subject to replay, though.
>
>
> On 05/03/2017 09:31 PM, Martin Thomson wrote:
>
> A clear delineation of security properties exists, if the handshake is
> done, then you are in the clear.  Otherwise, beware.  The separation
> of the streams doesn't help if you consider the possibility that 0-RTT
> data can be retroactively blessed.
>
>
> You can still be in trouble if you used the early exporter, e.g., for
> token binding.  We had some discussions in the tokbind session in Chicago
> that clarified that handshake completion does not retroactively bless the
> properties you want from 0-RTT token binding.
>
>
> -Ben
>
>
> ___
> 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] Security review of TLS1.3 0-RTT

[Benjamin Kaduk]

Trying to consolidate various things into a single mail...

On 05/04/2017 04:37 PM, Eric Rescorla wrote:
> In the PR I just posted, I spent most of my time describing the
> mechanisms and used a SHOULD-level requirement to do one of the
> mechanisms.
> I think there's a bunch of room to wordsmith the requirement. Perhaps
> we say:
>
> - You can't do 0-RTT without an application profile
> - Absent the application profile saying otherwise you SHOULD/MUST do
> one of these mitigations?
>
>

That seems like an inconsistent position to take (don't do this, but if
you ignore me, do this in this fashion).  Advising application profiles
to consider one of those things might be better.



On 05/04/2017 04:27 PM, Kyle Nekritz wrote:
>
> 2) Preventing clients from sending 0-RTT data multiple times (on
> separate connections) using the same PSK (for forward secrecy reasons)
>
>  
>
> I think this should be allowed. Otherwise, clients will not be able to
> retry 0-RTT requests that fail due to an unknown network error prior
> to receiving a NST (if they are out of cached PSKs). I’d expect the
> need for these retries to be larger with 0-RTT data, particularly when
> 0-RTT data is sent without even a transport roundtrip (in the case of
> TFO or QUIC). Servers are definitely not required to accept multiple
> 0-RTT connections using the same PSK, but I don’t think clients should
> be banned from attempting.
>

Obligatory note that if clients are forbidden from reusing a single PSK
for multiple 0-RTT, they can still use it for 1-RTT.



On 05/04/2017 03:24 PM, Colm MacCárthaigh wrote:
> On Thu, May 4, 2017 at 12:12 PM, Erik Nygren  > wrote:
>
> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla  > wrote:
>
>
> 1. A SHOULD-level requirement for server-side 0-RTT defense,
> explaining
> both session-cache and strike register styles and the merits
> of each.
>
>
> I don't believe this is technically viable for the large-scale
> server operators most interested in 0-RTT.
>
>
> I think it is (and work at one of the biggest) ... but if even it
> weren't, that would just imply that we can't have 0-RTT at all, not
> that it's ok to ship an insecure version.

I would be okay with that being the case ... but I don't think that's
actually the case.  Some people are going to do 0-RTT in one form or
another, whether or not we specify it here.  I'd rather have something
well-specified that can be used correctly in some cases and is
unfortunately used in more cases than that, then a
less-well-documented-and-analyzed thing used in those same questionable
cases.


On 05/03/2017 09:33 PM, Blumenthal, Uri - 0553 - MITLL wrote:
> P.S. Care to name (another :) one security-related protocol that
> doesn't provide replay protection?

Some of the earlier uses of Kerberos are subject to replay (hence
kerberos implementations can end up providing replay caches to try and
help, which are not perfect and slow to boot).  More modern exchanges
that use GSS acceptor subkeys are not subject to replay, though.


On 05/03/2017 09:31 PM, Martin Thomson wrote:
> A clear delineation of security properties exists, if the handshake is
> done, then you are in the clear.  Otherwise, beware.  The separation
> of the streams doesn't help if you consider the possibility that 0-RTT
> data can be retroactively blessed.

You can still be in trouble if you used the early exporter, e.g., for
token binding.  We had some discussions in the tokbind session in
Chicago that clarified that handshake completion does not retroactively
bless the properties you want from 0-RTT token binding.


-Ben

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Derrell Piper]

Sure, those are fine weasel words.  But do we really want to allow into this 
protocol something that can be misused with security implications in a protocol 
that’s attempting to solve a security problem?  I really don’t know.  I’m 
inclined to say, ‘no’ though.  For all those same reasons that IPsec provides 
replay detection, I think TLS should too.

Derrell

> On May 4, 2017, at 4:00 PM, Erik Nygren  wrote:
> 
> "The onus is on clients not to send messages in 0-RTT data which are not safe 
> to have replayed and which they would not be willing to retry across multiple 
> 1-RTT connections. The onus is on servers to protect themselves against 
> attacks employing 0-RTT data replication."
> 
> The server responsibility is a general property TLS can maintain while the 
> client responsibility requires an application profile to define.  

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Kyle Nekritz]

Yep, I think your PR is in the right direction.

> I have been basically assuming that you can't really do TLS without a 
> real-time clock, but maybe that's wrong?

Well, it’s possible, although I do not know if anyone actually does (and of 
course certificate validation would be a little challenging). Maybe someone 
from the embedded crowd can enlighten us.

> "For identities established externally an obfuscated_ticket_age of 0 SHOULD 
> be used, and servers MUST ignore the value."

Ah, I had missed that. I think the MUST might be a little strong there, even 
without direct involvement of the server in issuing the external PSK the ticket 
age can still be useful, for example using a similar method we use with Zero 
Protocol (Time-bound 0-RTT data section of 
https://code.facebook.com/posts/608854979307125/building-zero-protocol-for-fast-secure-mobile-connections/
 ).

From: Eric Rescorla [mailto:e...@rtfm.com]
Sent: Thursday, May 4, 2017 5:37 PM
To: Kyle Nekritz <knekr...@fb.com>
Cc: Colm MacCárthaigh <c...@allcosts.net>; tls@ietf.org
Subject: Re: [TLS] Security review of TLS1.3 0-RTT



On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz 
<knekr...@fb.com<mailto:knekr...@fb.com>> wrote:
> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining both 
> session-cache and strike register styles and the merits of each.

First, a point of clarification, I think two issues have been conflated in this 
long thread:
1) Servers rejecting replayed 0-RTT data (using a single use session 
cache/strike register/replay cache/some other method)

There are definitely cases (i.e. application profiles) where this should be 
done. I think a general case HTTPS server is one. But I don’t think this is 
strictly necessary across the board (for every application using 0-RTT at all). 
DNS was brought up earlier in this thread as an example of a protocol that is 
likely quite workable without extra measures to prevent replay.

We already state “Protocols MUST NOT use 0-RTT data without a profile that 
defines its use.”. We could also describe methods that may be used to provide 
further replay protection. But I don’t think it’s appropriate to make a blanket 
requirement that *all* application protocols should require it.

I also consider it quite misleading to say TLS 1.3 is insecure without such a 
recommendation. Uses of TLS can be insecure, that does not mean the protocol 
itself is. It’s insecure to use TLS without properly authenticating the server. 
Some users of TLS do not do this correctly. I’d actually argue that it is 
easier to mess this up than it is to mess up a 0-RTT deployment (and it can 
result in worse consequences). That doesn’t mean we should require a particular 
method of authentication, for all uses of TLS.

I think this is basically right. In the PR I just posted, I spent most of my 
time describing the
mechanisms and used a SHOULD-level requirement to do one of the mechanisms.
I think there's a bunch of room to wordsmith the requirement. Perhaps we say:

- You can't do 0-RTT without an application profile
- Absent the application profile saying otherwise you SHOULD/MUST do one of 
these mitigations?


2) Preventing clients from sending 0-RTT data multiple times (on separate 
connections) using the same PSK (for forward secrecy reasons)

I think this should be allowed. Otherwise, clients will not be able to retry 
0-RTT requests that fail due to an unknown network error prior to receiving a 
NST (if they are out of cached PSKs). I’d expect the need for these retries to 
be larger with 0-RTT data, particularly when 0-RTT data is sent without even a 
transport roundtrip (in the case of TFO or QUIC). Servers are definitely not 
required to accept multiple 0-RTT connections using the same PSK, but I don’t 
think clients should be banned from attempting.

I agree, and the PR I provided doesn't attempt to do so.


> 4. I would add to this that we recommend that proxy/CDN implementations 
> signal which data is 0-RTT and which is 1-RTT to the back-end (this was in 
> Colm's original message).

I’m not sure that the TLS 1.3 spec is the right place to make recommendations 
for this. I can see several reasonable approaches here, for example:
- Adding some kind of application level annotation (for example an HTTP header)
- Robustly preventing replay on the 0-RTT hop
- Sending proxied early data with a different TLS ContentType, etc.
I don’t see a need to specifically endorse any particular method here.

I think Colm has also agreed we shouldn't do this and it's not in my PR.



There was also a point brought up about the use of ticket_age without 0-RTT. 
I’m not aware of any use for ticket_age other than 0-RTT replay protection. I 
believe that ticket_age is sent with all PSKs mostly out of 
convenience/consistency. I don’t really have an objection to the current 
method, but I also wouldn’t be opposed to moving the ticket age to the early 
data

Re: [TLS] Security review of TLS1.3 0-RTT

[Eric Rescorla]

On Thu, May 4, 2017 at 3:00 PM, Erik Nygren  wrote:

> On Thu, May 4, 2017 at 5:37 PM, Eric Rescorla  wrote:
>
>>
>>
>>
>> On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz  wrote:
>>
>>> > 1. A SHOULD-level requirement for server-side 0-RTT defense,
>>> explaining both session-cache and strike register styles and the merits of
>>> each.
>>>
>>>
>>>
>>> First, a point of clarification, I think two issues have been conflated
>>> in this long thread:
>>>
>>> 1) Servers rejecting replayed 0-RTT data (using a single use session
>>> cache/strike register/replay cache/some other method)
>>>
>>>
>>>
>>> There are definitely cases (i.e. application profiles) where this should
>>> be done. I think a general case HTTPS server is one. But I don’t think this
>>> is strictly necessary across the board (for every application using 0-RTT
>>> at all). DNS was brought up earlier in this thread as an example of a
>>> protocol that is likely quite workable without extra measures to prevent
>>> replay.
>>>
>>>
>>>
>>> We already state “Protocols MUST NOT use 0-RTT data without a profile
>>> that defines its use.”. We could also describe methods that may be used to
>>> provide further replay protection. But I don’t think it’s appropriate to
>>> make a blanket requirement that *all* application protocols should require
>>> it.
>>>
>>>
>>>
>>> I also consider it quite misleading to say TLS 1.3 is insecure without
>>> such a recommendation. Uses of TLS can be insecure, that does not mean the
>>> protocol itself is. It’s insecure to use TLS without properly
>>> authenticating the server. Some users of TLS do not do this correctly. I’d
>>> actually argue that it is easier to mess this up than it is to mess up a
>>> 0-RTT deployment (and it can result in worse consequences). That doesn’t
>>> mean we should require a particular method of authentication, for all uses
>>> of TLS.
>>>
>>
>> I think this is basically right. In the PR I just posted, I spent most of
>> my time describing the
>> mechanisms and used a SHOULD-level requirement to do one of the
>> mechanisms.
>> I think there's a bunch of room to wordsmith the requirement. Perhaps we
>> say:
>>
>> - You can't do 0-RTT without an application profile
>> - Absent the application profile saying otherwise you SHOULD/MUST do one
>> of these mitigations?
>>
>
> I generally agree with Kyle here (and also added a few minor comments to
> the PR).
> I think we should be clear where the responsibilities generally lie as
> well, for example:
>
> "The onus is on clients not to send messages in 0-RTT data which are not
> safe to have replayed and which they would not be willing to retry across
> multiple 1-RTT connections. The onus is on servers to protect themselves
> against attacks employing 0-RTT data replication."
>
> The server responsibility is a general property TLS can maintain while the
> client responsibility requires an application profile to define.
>

These seem like good changes. I will work to incorporate them.

-Ekr


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

Re: [TLS] Security review of TLS1.3 0-RTT

[Erik Nygren]

On Thu, May 4, 2017 at 5:37 PM, Eric Rescorla  wrote:

>
>
>
> On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz  wrote:
>
>> > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
>> both session-cache and strike register styles and the merits of each.
>>
>>
>>
>> First, a point of clarification, I think two issues have been conflated
>> in this long thread:
>>
>> 1) Servers rejecting replayed 0-RTT data (using a single use session
>> cache/strike register/replay cache/some other method)
>>
>>
>>
>> There are definitely cases (i.e. application profiles) where this should
>> be done. I think a general case HTTPS server is one. But I don’t think this
>> is strictly necessary across the board (for every application using 0-RTT
>> at all). DNS was brought up earlier in this thread as an example of a
>> protocol that is likely quite workable without extra measures to prevent
>> replay.
>>
>>
>>
>> We already state “Protocols MUST NOT use 0-RTT data without a profile
>> that defines its use.”. We could also describe methods that may be used to
>> provide further replay protection. But I don’t think it’s appropriate to
>> make a blanket requirement that *all* application protocols should require
>> it.
>>
>>
>>
>> I also consider it quite misleading to say TLS 1.3 is insecure without
>> such a recommendation. Uses of TLS can be insecure, that does not mean the
>> protocol itself is. It’s insecure to use TLS without properly
>> authenticating the server. Some users of TLS do not do this correctly. I’d
>> actually argue that it is easier to mess this up than it is to mess up a
>> 0-RTT deployment (and it can result in worse consequences). That doesn’t
>> mean we should require a particular method of authentication, for all uses
>> of TLS.
>>
>
> I think this is basically right. In the PR I just posted, I spent most of
> my time describing the
> mechanisms and used a SHOULD-level requirement to do one of the mechanisms.
> I think there's a bunch of room to wordsmith the requirement. Perhaps we
> say:
>
> - You can't do 0-RTT without an application profile
> - Absent the application profile saying otherwise you SHOULD/MUST do one
> of these mitigations?
>

I generally agree with Kyle here (and also added a few minor comments to
the PR).
I think we should be clear where the responsibilities generally lie as
well, for example:

"The onus is on clients not to send messages in 0-RTT data which are not
safe to have replayed and which they would not be willing to retry across
multiple 1-RTT connections. The onus is on servers to protect themselves
against attacks employing 0-RTT data replication."

The server responsibility is a general property TLS can maintain while the
client responsibility requires an application profile to define.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Nico Williams]

On Thu, May 04, 2017 at 02:37:20PM -0700, Eric Rescorla wrote:
> On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz  wrote:
> > [...]
> 
> I think this is basically right. In the PR I just posted, I spent most of
> my time describing the
> mechanisms and used a SHOULD-level requirement to do one of the mechanisms.
> I think there's a bunch of room to wordsmith the requirement. Perhaps we
> say:
> 
> - You can't do 0-RTT without an application profile
> - Absent the application profile saying otherwise you SHOULD/MUST do one of
> these mitigations?

There's a number of ways to handle this.

One is to say that 0-rtt cannot be enabled by default, and that enabling
it requires an API call or application profile that puts the onus of
understanding the ramifications on the application developer.

The thing to keep in mind is that this RFC can give guidance to TLS
implementors, and to authors of Internet protocols using TLS.  It can't
really give guidance to authors of non-Internet protocols using TLS:
they might never look at the RFC.  So the guidance here has to be for
the available audience.  For TLS implementors the guidance should be to
make the 0-rtt footgun clear to consuming applications.

Nico
-- 

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Eric Rescorla]

On Thu, May 4, 2017 at 2:27 PM, Kyle Nekritz <knekr...@fb.com> wrote:

> > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
> both session-cache and strike register styles and the merits of each.
>
>
>
> First, a point of clarification, I think two issues have been conflated in
> this long thread:
>
> 1) Servers rejecting replayed 0-RTT data (using a single use session
> cache/strike register/replay cache/some other method)
>
>
>
> There are definitely cases (i.e. application profiles) where this should
> be done. I think a general case HTTPS server is one. But I don’t think this
> is strictly necessary across the board (for every application using 0-RTT
> at all). DNS was brought up earlier in this thread as an example of a
> protocol that is likely quite workable without extra measures to prevent
> replay.
>
>
>
> We already state “Protocols MUST NOT use 0-RTT data without a profile that
> defines its use.”. We could also describe methods that may be used to
> provide further replay protection. But I don’t think it’s appropriate to
> make a blanket requirement that *all* application protocols should require
> it.
>
>
>
> I also consider it quite misleading to say TLS 1.3 is insecure without
> such a recommendation. Uses of TLS can be insecure, that does not mean the
> protocol itself is. It’s insecure to use TLS without properly
> authenticating the server. Some users of TLS do not do this correctly. I’d
> actually argue that it is easier to mess this up than it is to mess up a
> 0-RTT deployment (and it can result in worse consequences). That doesn’t
> mean we should require a particular method of authentication, for all uses
> of TLS.
>

I think this is basically right. In the PR I just posted, I spent most of
my time describing the
mechanisms and used a SHOULD-level requirement to do one of the mechanisms.
I think there's a bunch of room to wordsmith the requirement. Perhaps we
say:

- You can't do 0-RTT without an application profile
- Absent the application profile saying otherwise you SHOULD/MUST do one of
these mitigations?


2) Preventing clients from sending 0-RTT data multiple times (on separate
> connections) using the same PSK (for forward secrecy reasons)
>
>
>
> I think this should be allowed. Otherwise, clients will not be able to
> retry 0-RTT requests that fail due to an unknown network error prior to
> receiving a NST (if they are out of cached PSKs). I’d expect the need for
> these retries to be larger with 0-RTT data, particularly when 0-RTT data is
> sent without even a transport roundtrip (in the case of TFO or QUIC).
> Servers are definitely not required to accept multiple 0-RTT connections
> using the same PSK, but I don’t think clients should be banned from
> attempting.
>

I agree, and the PR I provided doesn't attempt to do so.


> 4. I would add to this that we recommend that proxy/CDN implementations
> signal which data is 0-RTT and which is 1-RTT to the back-end (this was in
> Colm's original message).
>
>
>
> I’m not sure that the TLS 1.3 spec is the right place to make
> recommendations for this. I can see several reasonable approaches here, for
> example:
>
> - Adding some kind of application level annotation (for example an HTTP
> header)
>
> - Robustly preventing replay on the 0-RTT hop
>
> - Sending proxied early data with a different TLS ContentType, etc.
>
> I don’t see a need to specifically endorse any particular method here.
>

I think Colm has also agreed we shouldn't do this and it's not in my PR.


>
>
>
> There was also a point brought up about the use of ticket_age without
> 0-RTT. I’m not aware of any use for ticket_age other than 0-RTT replay
> protection. I believe that ticket_age is sent with all PSKs mostly out of
> convenience/consistency. I don’t really have an objection to the current
> method, but I also wouldn’t be opposed to moving the ticket age to the
> early data extension, so that it is only sent along with 0-RTT data.
>

I would be OK with this as well. It does seem slightly more elegant.




> It also seems a little under-specified what implementations unable to
> compute a reasonable ticket age should send (for example in the case of a
> device without a real time clock,
>

Right. I have been basically assuming that you can't really do TLS without
a real-time clock, but maybe that's wrong?



> or with an external PSK).
>

This actually is well-specified (though maybe wrong)
"For identities established externally an obfuscated_ticket_age of 0 SHOULD
be used, and servers MUST ignore the value."
https://tlswg.github.io/tls13-spec/#pre-shared-key-extension

-Ekr


> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Eric Rescorla
>

Re: [TLS] Security review of TLS1.3 0-RTT

[Kyle Nekritz]

> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining both 
> session-cache and strike register styles and the merits of each.

First, a point of clarification, I think two issues have been conflated in this 
long thread:
1) Servers rejecting replayed 0-RTT data (using a single use session 
cache/strike register/replay cache/some other method)

There are definitely cases (i.e. application profiles) where this should be 
done. I think a general case HTTPS server is one. But I don’t think this is 
strictly necessary across the board (for every application using 0-RTT at all). 
DNS was brought up earlier in this thread as an example of a protocol that is 
likely quite workable without extra measures to prevent replay.

We already state “Protocols MUST NOT use 0-RTT data without a profile that 
defines its use.”. We could also describe methods that may be used to provide 
further replay protection. But I don’t think it’s appropriate to make a blanket 
requirement that *all* application protocols should require it.

I also consider it quite misleading to say TLS 1.3 is insecure without such a 
recommendation. Uses of TLS can be insecure, that does not mean the protocol 
itself is. It’s insecure to use TLS without properly authenticating the server. 
Some users of TLS do not do this correctly. I’d actually argue that it is 
easier to mess this up than it is to mess up a 0-RTT deployment (and it can 
result in worse consequences). That doesn’t mean we should require a particular 
method of authentication, for all uses of TLS.

2) Preventing clients from sending 0-RTT data multiple times (on separate 
connections) using the same PSK (for forward secrecy reasons)

I think this should be allowed. Otherwise, clients will not be able to retry 
0-RTT requests that fail due to an unknown network error prior to receiving a 
NST (if they are out of cached PSKs). I’d expect the need for these retries to 
be larger with 0-RTT data, particularly when 0-RTT data is sent without even a 
transport roundtrip (in the case of TFO or QUIC). Servers are definitely not 
required to accept multiple 0-RTT connections using the same PSK, but I don’t 
think clients should be banned from attempting.

> 2. Document 0-RTT greasing in draft-ietf-tls-grease

I’m not convinced this is actually a productive thing to do in the same manner 
as grease, particularly if servers are taking anti-replay measures (in which 
case I see this being useful in a TLS testing tool like ssllabs, but not in 
actual deployments). I think we can leave this discussion for later though.

> 3. Adopt PR#448 (or some variant) so that session-id style implementations 
> provide PFS.

Sounds good to me.

> 4. I would add to this that we recommend that proxy/CDN implementations 
> signal which data is 0-RTT and which is 1-RTT to the back-end (this was in 
> Colm's original message).

I’m not sure that the TLS 1.3 spec is the right place to make recommendations 
for this. I can see several reasonable approaches here, for example:
- Adding some kind of application level annotation (for example an HTTP header)
- Robustly preventing replay on the 0-RTT hop
- Sending proxied early data with a different TLS ContentType, etc.
I don’t see a need to specifically endorse any particular method here.


There was also a point brought up about the use of ticket_age without 0-RTT. 
I’m not aware of any use for ticket_age other than 0-RTT replay protection. I 
believe that ticket_age is sent with all PSKs mostly out of 
convenience/consistency. I don’t really have an objection to the current 
method, but I also wouldn’t be opposed to moving the ticket age to the early 
data extension, so that it is only sent along with 0-RTT data.
It also seems a little under-specified what implementations unable to compute a 
reasonable ticket age should send (for example in the case of a device without 
a real time clock, or with an external PSK).

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Wednesday, May 3, 2017 11:13 PM
To: Colm MacCárthaigh <c...@allcosts.net>
Cc: tls@ietf.org
Subject: Re: [TLS] Security review of TLS1.3 0-RTT

[Deliberately responding to the OP rather than to anyone in particular]

Hi folks,

I'm seeing a lot of back and forth about general philosophy and the
wisdom of 0-RTT but I think it would be useful if we focused on what
changes, if any, we need to make to the draft.

I made some proposals yesterday
(https://www.ietf.org/mail-archive/web/tls/current/msg23088.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tls_current_msg23088.html=DwMFaQ=5VD0RTtNlTh3ycd41b3MUw=l2j4BjkO0Lc3u4CH2z7jPw=_2BECf9OfW1r1aRWrL_pSbQeKMshyOm2NIVWF4GGBI0=XgHbUwT6upAsOin4T6P8ePs8i0ZFsnD-_BNvueeq83E=>).

Specifically:
1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
both session-cache and strike register styles and the merits of each.

2. Document 0-RTT 

Re: [TLS] Security review of TLS1.3 0-RTT

[Eric Rescorla]

As promised:
https://github.com/tlswg/tls13-spec/pull/1005

Note: I may have to do a little post-landing cleanup, but I wanted to get
people's senses of the text ASAP.

Comments welcome.
-Ekr


On Wed, May 3, 2017 at 8:21 PM, Eric Rescorla  wrote:

>
>
> On Wed, May 3, 2017 at 8:20 PM, Colm MacCárthaigh 
> wrote:
>
>>
>>
>> On Wed, May 3, 2017 at 8:13 PM, Eric Rescorla  wrote:
>>
>>> I made some proposals yesterday
>>> (https://www.ietf.org/mail-archive/web/tls/current/msg23088.html).
>>>
>>> Specifically:
>>> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
>>> both session-cache and strike register styles and the merits of each.
>>>
>>> 2. Document 0-RTT greasing in draft-ietf-tls-grease
>>>
>>> 3. Adopt PR#448 (or some variant) so that session-id style
>>> implementations
>>> provide PFS.
>>>
>>> 4. I would add to this that we recommend that proxy/CDN implementations
>>> signal which data is 0-RTT and which is 1-RTT to the back-end (this was
>>> in
>>> Colm's original message).
>>>
>>
>> This all sounds great to me. I'm not sure that we need (4.) if we have
>> (1.).  I think with (1.) - recombobulating to a single stream might even be
>> best overall, to reduce application complexity, and it seems to be what
>> most implementors are actually doing.
>>
>> I know that leaves the DKG attack, but from a client and servers
>> perspective that attack is basically identical to a server timeout, and
>> it's something that systems likely have some fault tolerance around. It's
>> not /new/ broken-ness.
>>
>
> Heh. Always happy to do less writing.
>
> Thanks,
> -Ekr
>
>
>>
>>
>>> Based on Colm's response, I think these largely hits the points he made
>>> in his original message.
>>>
>>> There's already a PR for #3 and I'll have PRs for #1 and #4 tomorrow.
>>> What would be most helpful to me as Editor would be if people could
>>> review
>>> these PRs and/or suggest other specific changes that we should make
>>> to the document.
>>>
>>
>> Will do! Many thanks.
>>
>> --
>> Colm
>>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Security review of TLS1.3 0-RTT

[Nico Williams]

On Thu, May 04, 2017 at 01:21:43PM -0700, Colm MacCárthaigh wrote:
> On Thu, May 4, 2017 at 12:39 PM, Nico Williams 
> wrote:
> > The SHOULD should say that the server-side needs to apply a replay cache
> > OR fallback onto a full exchange when the 0-rtt data payload involves a
> > non-idempotent operation.
> 
> I don't mean to be dismissive with this but TLS stands for "Transport Layer
> Security". The transport layer just isn't aware of what the operations are,
> and whether then can be idempotent (99% of the time, the answer is "no").
> Only the application can tell, but this violation of layers is what leads
> to so many problems. I don't think it's workable.

I don't mean to be dismissive, but it doesn't matter what "TLS" stands
for.  It does what we make it do via Standards Action at the IETF.  We
follow our rules for everything to do with development of Internet
Standards and publication of Experimental, Informational and BCP RFCs.

We have a process.  If you don't like what we're doing, you can voice
your opinion.  If you don't like the outcome of consensus calls and/or
IESG decisions, you can appeal those.

Thanks,

Nico
-- 

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Thu, May 4, 2017 at 12:12 PM, Erik Nygren  wrote:

> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla  wrote:
>
>>
>> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
>> both session-cache and strike register styles and the merits of each.
>>
>
> I don't believe this is technically viable for the large-scale server
> operators most interested in 0-RTT.
>

I think it is (and work at one of the biggest) ... but if even it weren't,
that would just imply that we can't have 0-RTT at all, not that it's ok to
ship an insecure version.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Thu, May 4, 2017 at 12:39 PM, Nico Williams 
wrote:

> The SHOULD should say that the server-side needs to apply a replay cache
> OR fallback onto a full exchange when the 0-rtt data payload involves a
> non-idempotent operation.
>

I don't mean to be dismissive with this but TLS stands for "Transport Layer
Security". The transport layer just isn't aware of what the operations are,
and whether then can be idempotent (99% of the time, the answer is "no").
Only the application can tell, but this violation of layers is what leads
to so many problems. I don't think it's workable.


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

Re: [TLS] Security review of TLS1.3 0-RTT

[Nico Williams]

On Thu, May 04, 2017 at 02:49:20PM -0500, Nico Williams wrote:
> On Thu, May 04, 2017 at 02:44:06PM -0500, Benjamin Kaduk wrote:
> > On 05/04/2017 02:39 PM, Nico Williams wrote:
> > > The SHOULD should say that the server-side needs to apply a replay cache
> > > OR fallback onto a full exchange when the 0-rtt data payload involves a
> > > non-idempotent operation.
> > 
> > You seem confused on this key point.  The server commits to accepting or
> > rejecting *all* early data, *before* it can look inside and see what it
> > is (in particular, whether or not it is idempotent).
> 
> Sure, that's fine.  You could run an HTTP server that only accepts
> HEADs, GETs, maybe DELETEs, and accepts 0-rtt and have the client send
> all POSTs and such to a different HTTP server.

Also, a server could accept all sorts of 0-rtt data and at the
application-layer cause extra round-trips and force the client to
re-request.  Not all existing application protocols will support that,
naturally.  For HTTP... maybe a redirect?

Nico
-- 

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Nico Williams]

On Thu, May 04, 2017 at 11:01:02PM +0300, Ilari Liusvaara wrote:
> On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote:
> > On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla  wrote:
> > > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
> > > both session-cache and strike register styles and the merits of each.
> 
> > Many of the discussions I've been in seem to have concluded that we should
> > always be assuming that 0-RTT data can and will be replayed, and
> > applications and application protocols need to design and use it
> > carefully, accordingly.
> 
> The problem is, the amount of replays is so great even non-idempotency
> that is normally of no consequence becomes a major problem. It isn't one
> or two or three replays, it could be _millions_ of replays.

Adaptive fallback to full handshakes.

> Almost nothing is idempotent enough, unless extremely carefully designed,
> and very few things are.

GETs of static data are.

> There are loads of GET endpoints there that don't have any wild non-
> idempotent behaviour, but still aren't idempotent enough.

Yes, this is true.  But the idea is that one should not enable 0-rtt for
servers that have such behavior.

Nico
-- 

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Nico Williams]

On Thu, May 04, 2017 at 02:44:06PM -0500, Benjamin Kaduk wrote:
> On 05/04/2017 02:39 PM, Nico Williams wrote:
> > On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote:
> >> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla  wrote:
> >>> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
> >>> both session-cache and strike register styles and the merits of each.
> > The SHOULD should say that the server-side needs to apply a replay cache
> > OR fallback onto a full exchange when the 0-rtt data payload involves a
> > non-idempotent operation.
> 
> You seem confused on this key point.  The server commits to accepting or
> rejecting *all* early data, *before* it can look inside and see what it
> is (in particular, whether or not it is idempotent).

Sure, that's fine.  You could run an HTTP server that only accepts
HEADs, GETs, maybe DELETEs, and accepts 0-rtt and have the client send
all POSTs and such to a different HTTP server.

> > [...]
> 
> Which is why we (try to) make such a big deal about having an
> application profile -- to write down what is actually idempotent.

It's one good reason, but we were doing that ages ago, before 0-rtt was
ever proposed.  (Well, Kerberos has a 0-rtt scheme, with very little
guidance on this point...)

Nico
-- 

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Benjamin Kaduk]

On 05/04/2017 02:39 PM, Nico Williams wrote:
> On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote:
>> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla  wrote:
>>> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
>>> both session-cache and strike register styles and the merits of each.
> The SHOULD should say that the server-side needs to apply a replay cache
> OR fallback onto a full exchange when the 0-rtt data payload involves a
> non-idempotent operation.

You seem confused on this key point.  The server commits to accepting or
rejecting *all* early data, *before* it can look inside and see what it
is (in particular, whether or not it is idempotent).

>
>> Many of the discussions I've been in seem to have concluded that we
>> should always be assuming that 0-RTT data can and will be replayed,
>> and applications and application protocols need to design and use it
>> carefully, accordingly.
> Correct.  See the above text about idempotency.
>
>

Which is why we (try to) make such a big deal about having an
application profile -- to write down what is actually idempotent.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Nico Williams]

On Thu, May 04, 2017 at 03:12:41PM -0400, Erik Nygren wrote:
> On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla  wrote:
> > 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
> > both session-cache and strike register styles and the merits of each.

The SHOULD should say that the server-side needs to apply a replay cache
OR fallback onto a full exchange when the 0-rtt data payload involves a
non-idempotent operation.

> I don't believe this is technically viable for the large-scale server
> operators most interested in 0-RTT.  Having session ticket reuse across
> clusters is a requirement for performance, especially in cases such as
> moving load between clusters.  In the cross-cluster case, neither session
> caches nor strike registers are possible in the time-frames that are
> interesting and relevant to 0-RTT (as strong consistency between clusters
> has inherent latency that isn't possible in the 0-RTT time-frames).

Making the SHOULD be about non-idempotent 0-rtt payloads is sufficient.

That is, if you're GETting something and the server correctly makes GET
idempotent, then you can accept 0-rtt without any replay cache checking.

A POST, on the other hand, should get the fallback-to-full-handshake
treatment.  (And, indeed, the application should not even bother with a
0-rtt POST.)

> I fear having a "SHOULD" requirement here is one that will be widely
> ignored.

It should not be ignored as to non-idempotent operations though!

> Anything stateful here defeats the purpose of session tickets [...]

Right.

> Many of the discussions I've been in seem to have concluded that we
> should always be assuming that 0-RTT data can and will be replayed,
> and applications and application protocols need to design and use it
> carefully, accordingly.

Correct.  See the above text about idempotency.

Nico
-- 

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Erik Nygren]

On Wed, May 3, 2017 at 11:13 PM, Eric Rescorla  wrote:

>
> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
> both session-cache and strike register styles and the merits of each.
>

I don't believe this is technically viable for the large-scale server
operators most interested in 0-RTT.  Having session ticket reuse across
clusters is a requirement for performance, especially in cases such as
moving load between clusters.  In the cross-cluster case, neither session
caches nor strike registers are possible in the time-frames that are
interesting and relevant to 0-RTT (as strong consistency between clusters
has inherent latency that isn't possible in the 0-RTT time-frames).

I fear having a "SHOULD" requirement here is one that will be widely
ignored.

Anything stateful here defeats the purpose of session tickets and is also
far too vulnerable to DDoS attacks to be useful, especially when trying to
scale up
to large clusters.

Many of the discussions I've been in seem to have concluded that we should
always be assuming that 0-RTT data can and will be replayed, and
applications
and application protocols need to design and use it carefully, accordingly.

Some of these mechanisms (timestamps, strike registers, etc)
are useful for servers protecting themselves from DDoS attacks
but aren't useful against an adversary trying to actively exploit replays.


4. I would add to this that we recommend that proxy/CDN implementations
> signal which data is 0-RTT and which is 1-RTT to the back-end (this was in
> Colm's original message).
>

I'm not entirely sure what back-ends are going to do here.  By the time
they gain visibility into this it is too late.

As some of us have been saying for awhile, we need to assume that 0-RTT
data is replayable and require application protocols and clients
implementing those protocols to define when and when it is not safe to
use.  For example, if exporters from 0RTT are not safe to use, we should
make that super-clear that this is not a safe use of 0RTT.

In the HTTP case, Patrick McManus has pointed out that many
application-layer clients will retry/replay non-idempotent POST operations
regardless even over 1RTT (and if the app doesn't, the user will just click
reload).  The best defense against these classes of issues is for
end-to-end application semantics rather than trying to provide properties
at the session  layer.

Erik




> On Tue, May 2, 2017 at 7:44 AM, Colm MacCárthaigh 
> wrote:
>
>> On Sunday at the TLS:DIV workshop I presented a summary of findings of a
>> security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2n.
>> Thanks to feedback in the room I've now tightened up the findings from the
>> review and posted them as an issue on the draft GitHub repo:
>>
>> https://github.com/tlswg/tls13-spec/issues/1001
>>
>> I'll summarize the summary: Naturally the focus was on forward secrecy
>> and replay. On forward secrecy the main finding was that it's not necessary
>> to trade off Forward Secrecy and 0-RTT. A single-use session cache can
>> provide it, and with the modification that ekr has created in
>> https://github.com/tlswg/tls13-spec/pull/998 , such a cache works for
>> both pre-auth and post-auth tickets, and it allows clients to build up
>> pools of meaningfully distinct tickets.
>>
>> There's also an observation there that it should really be that clients
>> "MUST" use tickets only once. Any re-use likely discloses the obfuscated
>> ticket age, which is intended to be secret. Right now it's a "SHOULD".
>>
>> On replay, the main finding is that what's in the draft is not workably
>> secure, and the review includes 5 different attacks against 0-RTT data to
>> illustrate that. Attacks 1 and 2 show that the kind of replay permitted by
>> the draft is very different from the kind of replay permitted by dkg's
>> existing downgrade-and-retry attack. I also go over why it very very
>> difficult to many applications to achieve that idempotency, and why one
>> idempotency pattern actually relies on non-replayable messages.
>>
>> Attack 3 shows that idempotency is not sufficient, applications must also
>> be free of measurable side-effects, which is not practical.  Attack 4 shows
>> that 0-RTT breaks a common security mechanism: spoofing-resistant
>> throttles. Attack 5 shows that 0-RTT replay-ability enables an additional
>> form of traffic analysis.
>>
>> The recommendation in the review is that implementations "MUST" prevent
>> replays of 0-RTT section, with some additional discussion about why the
>> existing advice is unlikely to be followed, and why consistent
>> interoperability matters here.
>>
>> Unfortunately, I wasn't aware until Friday that this review would be
>> coming so late in the TLD1.3 draft process, and my apologies for that. I am
>> now planning to attend the future WG in-person meetings and look forward to
>> seeing many of you there.
>>
>> --
>> Colm
>>
>> 

Re: [TLS] Security review of TLS1.3 0-RTT

[Andrei Popov]

Indeed, as long as the scope of the ticket <= scope of the nonce database, it 
appears that rerouting wont’ help the attacker.
From: Colm MacCárthaigh [mailto:c...@allcosts.net]
Sent: Thursday, May 4, 2017 11:33 AM
To: Andrei Popov <andrei.po...@microsoft.com>
Cc: Ilari Liusvaara <ilariliusva...@welho.com>; tls@ietf.org
Subject: Re: [TLS] Security review of TLS1.3 0-RTT

On Thu, May 4, 2017 at 11:29 AM, Andrei Popov 
<andrei.po...@microsoft.com<mailto:andrei.po...@microsoft.com>> wrote:

  *   Providers already work hard to maximize user affinity to a data center 
for other operational reasons; re-routing is relatively rare and quickly 
repaired by issuing a new ticket.
Understood, but isn’t an attacker going to be able to re-route at will?

Yes, but I don't see the significance.  If the attacker reroutes the user, or 
replays a ticket, to a different data center - the ticket won't work, it'll 
degrade gracefully to a regular connection.  Of course the attacker succeeded 
in slowing the user down, but that's possible anyway.

Maybe you're thinking of a strike register that shares a global namespace? That 
would be an implementation error; tickets should be scoped to the location they 
are issued from, and checked against its strike register (or not used at all).

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Thu, May 4, 2017 at 11:29 AM, Andrei Popov 
wrote:

>
>- Providers already work hard to maximize user affinity to a data
>center for other operational reasons; re-routing is relatively rare and
>quickly repaired by issuing a new ticket.
>
> Understood, but isn’t an attacker going to be able to re-route at will?
>

Yes, but I don't see the significance.  If the attacker reroutes the user,
or replays a ticket, to a different data center - the ticket won't work,
it'll degrade gracefully to a regular connection.  Of course the attacker
succeeded in slowing the user down, but that's possible anyway.

Maybe you're thinking of a strike register that shares a global namespace?
That would be an implementation error; tickets should be scoped to the
location they are issued from, and checked against its strike register (or
not used at all).

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Andrei Popov]

  *   Providers already work hard to maximize user affinity to a data center 
for other operational reasons; re-routing is relatively rare and quickly 
repaired by issuing a new ticket.
Understood, but isn’t an attacker going to be able to re-route at will?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Thu, May 4, 2017 at 11:22 AM, Andrei Popov 
wrote:

>
>- I don't think we'll have a problem implementing a single use cache,
>strike register, we have similar systems for other services, at higher
>volumes.
>
> … and these things work across geographically distributed datacenters,
> without negating the latency benefits of 0-RTT?
>

They won't work across geographically distributed data centers, no, but I
don't think that's a significant problem. Providers already work hard to
maximize user affinity to a data center for other operational reasons;
re-routing is relatively rare and quickly repaired by issuing a new ticket.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Andrei Popov]

  *   I don't think we'll have a problem implementing a single use cache, 
strike register, we have similar systems for other services, at higher volumes.
… and these things work across geographically distributed datacenters, without 
negating the latency benefits of 0-RTT?

Cheers,

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Thu, May 4, 2017 at 10:07 AM, Andrei Popov 
wrote:

> IMHO what we have is a facility in TLS 1.3 that:
> 1. Requires extraordinary effort on the server side to mitigate replay
> (for all but the smallest deployments);
> 2. Offers no way for the client to determine whether the server is
> mitigating replay (before replay becomes possible);
>

I'm less worried about these problems. There's a nice property that the
operators of large deployments tend to also be technically sophisticated. I
don't think we'll have a problem implementing a single use cache, strike
register, we have similar systems for other services, at higher volumes.
It's a cost of being big, and that's ok.

It will be possible to tell whether a service permits replays; by trying
them. If the service permits them, that's a pretty clear CVE, and the usual
incentives work as well as they usually do.


> 3. Is trivial to enable on the client and improves connection latency;
> 4. Eliminates a nonce that other protocols (used to) rely on.
>
> While it is true that there are cases where this facility is beneficial,
> there is no doubt that it will be widely misused, in both applications and
> protocols.
>

This doesn't need to be an anchor around the neck of the whole feature.
0-RTT is still an awesome speed benefit - if servers prevent replays, I
think we have a very good balance.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Andrei Popov]

IMHO what we have is a facility in TLS 1.3 that:
1. Requires extraordinary effort on the server side to mitigate replay (for all 
but the smallest deployments);
2. Offers no way for the client to determine whether the server is mitigating 
replay (before replay becomes possible);
3. Is trivial to enable on the client and improves connection latency;
4. Eliminates a nonce that other protocols (used to) rely on.

While it is true that there are cases where this facility is beneficial, there 
is no doubt that it will be widely misused, in both applications and protocols.

Cheers,

Andrei

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara
Sent: Thursday, May 4, 2017 2:35 AM
To: Colm MacCárthaigh <c...@allcosts.net>
Cc: tls@ietf.org
Subject: Re: [TLS] Security review of TLS1.3 0-RTT

On Tue, May 02, 2017 at 07:44:35AM -0700, Colm MacCárthaigh wrote:
> On Sunday at the TLS:DIV workshop I presented a summary of findings of 
> a security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2n.
> Thanks to feedback in the room I've now tightened up the findings from 
> the review and posted them as an issue on the draft GitHub repo:
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> b.com%2Ftlswg%2Ftls13-spec%2Fissues%2F1001=02%7C01%7CAndrei.Popov
> %40microsoft.com%7C51d7739d6f4341108acb08d492d0cd8f%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C636294872882067868=HTQL9a3CxUEC0GkAQ%
> 2BviRMMO5ts2PnifQjOaZ%2BLZXR8%3D=0

What I didn't see in the summary, but I think might be relevant in relation to 
0-RTT:

There is a thing called 0-RTT exporter, which are exporter values available 
during 0-RTT transmission.

If the server uses 0-RTT exporter and doesn't enforce non-replay, the value 
grossly fails to be "nonce", which means it is likely unsafe to use for 
authentication.

Unfortunately, there are protocols that are already discussing the use of TLS 
1.3 0-RTT exporter, and switching to "full" exporter.
Unfortunately, the easiest way is not to switch, which means the possibly weak 
0-RTT exporter will be used for authenticating even non-replayable data.



-Ilari

___
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=02%7C01%7CAndrei.Popov%40microsoft.com%7C51d7739d6f4341108acb08d492d0cd8f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636294872882067868=sgnwm3v7jfjLeWHZV77zwpchfzgy85ASKeKYYxEQxss%3D=0
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Security review of TLS1.3 0-RTT

[Ilari Liusvaara]

On Tue, May 02, 2017 at 07:44:35AM -0700, Colm MacCárthaigh wrote:
> On Sunday at the TLS:DIV workshop I presented a summary of findings of a
> security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2n.
> Thanks to feedback in the room I've now tightened up the findings from the
> review and posted them as an issue on the draft GitHub repo:
> 
> https://github.com/tlswg/tls13-spec/issues/1001

What I didn't see in the summary, but I think might be relevant in
relation to 0-RTT:

There is a thing called 0-RTT exporter, which are exporter values
available during 0-RTT transmission.

If the server uses 0-RTT exporter and doesn't enforce non-replay, the
value grossly fails to be "nonce", which means it is likely unsafe to
use for authentication.

Unfortunately, there are protocols that are already discussing the
use of TLS 1.3 0-RTT exporter, and switching to "full" exporter.
Unfortunately, the easiest way is not to switch, which means the
possibly weak 0-RTT exporter will be used for authenticating even
non-replayable data.



-Ilari

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Eric Rescorla]

On Wed, May 3, 2017 at 8:20 PM, Colm MacCárthaigh  wrote:

>
>
> On Wed, May 3, 2017 at 8:13 PM, Eric Rescorla  wrote:
>
>> I made some proposals yesterday
>> (https://www.ietf.org/mail-archive/web/tls/current/msg23088.html).
>>
>> Specifically:
>> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
>> both session-cache and strike register styles and the merits of each.
>>
>> 2. Document 0-RTT greasing in draft-ietf-tls-grease
>>
>> 3. Adopt PR#448 (or some variant) so that session-id style implementations
>> provide PFS.
>>
>> 4. I would add to this that we recommend that proxy/CDN implementations
>> signal which data is 0-RTT and which is 1-RTT to the back-end (this was in
>> Colm's original message).
>>
>
> This all sounds great to me. I'm not sure that we need (4.) if we have
> (1.).  I think with (1.) - recombobulating to a single stream might even be
> best overall, to reduce application complexity, and it seems to be what
> most implementors are actually doing.
>
> I know that leaves the DKG attack, but from a client and servers
> perspective that attack is basically identical to a server timeout, and
> it's something that systems likely have some fault tolerance around. It's
> not /new/ broken-ness.
>

Heh. Always happy to do less writing.

Thanks,
-Ekr


>
>
>> Based on Colm's response, I think these largely hits the points he made
>> in his original message.
>>
>> There's already a PR for #3 and I'll have PRs for #1 and #4 tomorrow.
>> What would be most helpful to me as Editor would be if people could review
>> these PRs and/or suggest other specific changes that we should make
>> to the document.
>>
>
> Will do! Many thanks.
>
> --
> Colm
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Wed, May 3, 2017 at 8:13 PM, Eric Rescorla  wrote:

> I made some proposals yesterday
> (https://www.ietf.org/mail-archive/web/tls/current/msg23088.html).
>
> Specifically:
> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
> both session-cache and strike register styles and the merits of each.
>
> 2. Document 0-RTT greasing in draft-ietf-tls-grease
>
> 3. Adopt PR#448 (or some variant) so that session-id style implementations
> provide PFS.
>
> 4. I would add to this that we recommend that proxy/CDN implementations
> signal which data is 0-RTT and which is 1-RTT to the back-end (this was in
> Colm's original message).
>

This all sounds great to me. I'm not sure that we need (4.) if we have
(1.).  I think with (1.) - recombobulating to a single stream might even be
best overall, to reduce application complexity, and it seems to be what
most implementors are actually doing.

I know that leaves the DKG attack, but from a client and servers
perspective that attack is basically identical to a server timeout, and
it's something that systems likely have some fault tolerance around. It's
not /new/ broken-ness.


> Based on Colm's response, I think these largely hits the points he made
> in his original message.
>
> There's already a PR for #3 and I'll have PRs for #1 and #4 tomorrow.
> What would be most helpful to me as Editor would be if people could review
> these PRs and/or suggest other specific changes that we should make
> to the document.
>

Will do! Many thanks.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Peter Gutmann]

Nico Williams  writes:

>Yeah, but a non-persistent clock is fine if the client can learn time from
>the server (and keep a different offset from system time to every server if
>need be, learning system time from one of them, or from NTP, or whatever).

In many cases neither the server nor the client have clocks.  They also don't
have much provision for keeping track of persistent state across devices.

Overall though it's a bit of a moot point because it's unlikely these devices
will ever do TLS 1.3 (it's going to be enough of a pain eventually moving them
to 1.2), I was just pointing out that you can't assume the presence of a
clock.  It may be perfectly OK to assume that anything that'll ever do 1.3
also has an accurate(ish) time source available.

Peter.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Eric Rescorla]

[Deliberately responding to the OP rather than to anyone in particular]

Hi folks,

I'm seeing a lot of back and forth about general philosophy and the
wisdom of 0-RTT but I think it would be useful if we focused on what
changes, if any, we need to make to the draft.

I made some proposals yesterday
(https://www.ietf.org/mail-archive/web/tls/current/msg23088.html).

Specifically:
1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
both session-cache and strike register styles and the merits of each.

2. Document 0-RTT greasing in draft-ietf-tls-grease

3. Adopt PR#448 (or some variant) so that session-id style implementations
provide PFS.

4. I would add to this that we recommend that proxy/CDN implementations
signal which data is 0-RTT and which is 1-RTT to the back-end (this was in
Colm's original message).

Based on Colm's response, I think these largely hits the points he made
in his original message.

There's already a PR for #3 and I'll have PRs for #1 and #4 tomorrow.
What would be most helpful to me as Editor would be if people could review
these PRs and/or suggest other specific changes that we should make
to the document.

Thanks,
-Ekr




On Tue, May 2, 2017 at 7:44 AM, Colm MacCárthaigh  wrote:

> On Sunday at the TLS:DIV workshop I presented a summary of findings of a
> security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2n.
> Thanks to feedback in the room I've now tightened up the findings from the
> review and posted them as an issue on the draft GitHub repo:
>
> https://github.com/tlswg/tls13-spec/issues/1001
>
> I'll summarize the summary: Naturally the focus was on forward secrecy and
> replay. On forward secrecy the main finding was that it's not necessary to
> trade off Forward Secrecy and 0-RTT. A single-use session cache can provide
> it, and with the modification that ekr has created in
> https://github.com/tlswg/tls13-spec/pull/998 , such a cache works for
> both pre-auth and post-auth tickets, and it allows clients to build up
> pools of meaningfully distinct tickets.
>
> There's also an observation there that it should really be that clients
> "MUST" use tickets only once. Any re-use likely discloses the obfuscated
> ticket age, which is intended to be secret. Right now it's a "SHOULD".
>
> On replay, the main finding is that what's in the draft is not workably
> secure, and the review includes 5 different attacks against 0-RTT data to
> illustrate that. Attacks 1 and 2 show that the kind of replay permitted by
> the draft is very different from the kind of replay permitted by dkg's
> existing downgrade-and-retry attack. I also go over why it very very
> difficult to many applications to achieve that idempotency, and why one
> idempotency pattern actually relies on non-replayable messages.
>
> Attack 3 shows that idempotency is not sufficient, applications must also
> be free of measurable side-effects, which is not practical.  Attack 4 shows
> that 0-RTT breaks a common security mechanism: spoofing-resistant
> throttles. Attack 5 shows that 0-RTT replay-ability enables an additional
> form of traffic analysis.
>
> The recommendation in the review is that implementations "MUST" prevent
> replays of 0-RTT section, with some additional discussion about why the
> existing advice is unlikely to be followed, and why consistent
> interoperability matters here.
>
> Unfortunately, I wasn't aware until Friday that this review would be
> coming so late in the TLD1.3 draft process, and my apologies for that. I am
> now planning to attend the future WG in-person meetings and look forward to
> seeing many of you there.
>
> --
> 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] Security review of TLS1.3 0-RTT

[Blumenthal, Uri - 0553 - MITLL]

Chose not to provide replay protection?! I have to agree with Colm - it doesn't 
sound good. 

Care to justify?

P.S. Care to name (another :) one security-related protocol that doesn't 
provide replay protection?

Regards,
Uri

Sent from my iPhone

> On May 3, 2017, at 21:42, Colm MacCárthaigh  wrote:
> 
> 
> 
>> On Wed, May 3, 2017 at 6:11 PM, Watson Ladd  wrote:
>> Historically TLS protected against replay attacks. Now it doesn't. An
>> application that relies on this property which TLS used to guarantee
>> is now broken. Clearly we could have provided it, we just chose not
>> to.
> 
> And that choice is insecure. If it's to be kept, I'd suggest renaming the 
> protocol. 
> 
> -- 
> Colm
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Wed, May 3, 2017 at 6:59 PM, Viktor Dukhovni 
wrote:

>
> > On May 3, 2017, at 9:39 PM, Colm MacCárthaigh  wrote:
> >
> > As it happens, DNS queries are not idempotent.  Queries have
> side-effects,
>
> This is sufficiently misleading to be false.


What I'm trying to get at is that idempotency is hard. Even the simplest
things that seem idempotent often are not. It's really really hard to do a
deep review. And that's if people even know to perform the review.

,

> Many providers throttle DNS queries (and TLS is intended as a mechanism
> > to help prevent the ordinary spoof ability of DNS queries).
>
> Again the client is unauthenticated, throttling is by IP address, there's
> no need to repeat the same payload, indeed that's less effective since
> throttling is biased towards queries for non-existent names, ...
>

It's not always by IP address. Anti-DDOS is much more nuanced in my
experience, often take the QNAME into account.

>
> Throttling is mostly for UDP, for lack of BCP-38 implementation.  DNS
> over TLS *is* a good candidate for 0-RTT.  [ I would have chosen a more
> simple protocol for DNS security than TLS, but given that DNS over TLS
> seems to be moving forward, 0-RTT makes sense. ]
>

+1 to that too!

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Wed, May 3, 2017 at 6:19 PM, Viktor Dukhovni 
wrote:

> One obvious use case for 0-RTT is DNS queries.  The query protocol is
> idempotent, and latency matters.  So for DNS over TLS, 0-RTT would be
> a good fit.   TLS session caches are not attractive on the DNS server
> given the enormous query volumes, but STEKs would be a good fit.
>

As it happens, DNS queries are not idempotent.  Queries have side-effects,
for example Bind9 will rotate an RRset by one increment on each query.
Many providers charge by the DNS query. Many providers throttle DNS queries
(and TLS is intended as a mechanism to help prevent the ordinary spoof
ability of DNS queries).


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

Re: [TLS] Security review of TLS1.3 0-RTT

[Salz, Rich]

> Let's get the fallacy out of the way.  TLS 1.3 provides protection against 
> replay
> attacks, just not if you decide to use 0-RTT.
> 
> I realize that there is a real risk that this distinction will be lost on 
> some, but I
> can fairly confidently say that it isn't lost on those who are considering 
> its use
> in various protocols.

Well, for example, Chrome/boringSSL should arguably know better but are 
treating it all as one equivalent stream.

Is FF/NSS doing the same thing?

Why?

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Viktor Dukhovni]

> On May 3, 2017, at 9:15 PM, Martin Thomson  wrote:
> 
> Let's get the fallacy out of the way.  TLS 1.3 provides protection
> against replay attacks, just not if you decide to use 0-RTT.

Amen.

> I realize that there is a real risk that this distinction will be lost
> on some, but I can fairly confidently say that it isn't lost on those
> who are considering its use in various protocols.  For instance, I've
> spoken to someone who is looking at XMPP seriously and the advice
> there is pretty close to *don't* use 0-RTT.

One obvious use case for 0-RTT is DNS queries.  The query protocol is
idempotent, and latency matters.  So for DNS over TLS, 0-RTT would be
a good fit.   TLS session caches are not attractive on the DNS server
given the enormous query volumes, but STEKs would be a good fit.

-- 
Viktor.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Martin Thomson]

On 4 May 2017 at 11:11, Watson Ladd  wrote:
> Historically TLS protected against replay attacks. Now it doesn't. An
> application that relies on this property which TLS used to guarantee
> is now broken. Clearly we could have provided it, we just chose not
> to.

Let's get the fallacy out of the way.  TLS 1.3 provides protection
against replay attacks, just not if you decide to use 0-RTT.

I realize that there is a real risk that this distinction will be lost
on some, but I can fairly confidently say that it isn't lost on those
who are considering its use in various protocols.  For instance, I've
spoken to someone who is looking at XMPP seriously and the advice
there is pretty close to *don't* use 0-RTT.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Watson Ladd]

On Wed, May 3, 2017 at 3:56 PM, Martin Thomson  wrote:
> On 3 May 2017 at 22:45, Colm MacCárthaigh  wrote:
>> This is easy to say; the TLS layer is the right place. It is not practical
>> for applications to defend themselves, especially from timing attacks.
>
> If you care about these attacks as much as it appears, then you can't
> reasonably take this position.  We've historically done a lot to
> secure applications at a single point, and we're almost at the end of
> what we can reasonably do for them at this layer.  We need to think
> more hollistically and acknowledge that applications need to take some
> responsibility for their own security.

Historically TLS protected against replay attacks. Now it doesn't. An
application that relies on this property which TLS used to guarantee
is now broken. Clearly we could have provided it, we just chose not
to.

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



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Wed, May 3, 2017 at 5:51 PM, Viktor Dukhovni 
wrote:
>
> > On May 3, 2017, at 6:29 PM, Colm MacCárthaigh  wrote:
> >
> > Pervasive forward secrecy is one of the central security goals of modern
> > cryptography,
>
> Sure, given a sensible definition of forward-secrecy.  And near instanenous
> deletion of session keys is not part of such a definition.
>

I want to re-run DH for every bit transferred! of course I'm kidding, and
take your point. There's a balance to strike.


> > STEKs aren't compatible with this goal. They may be acceptable
> operationally
> > today, but I think they must be borrowed time if the central goal is
> meaningful.
>
> We need to recall what thread-model is behind the desire for
> forward-secrecy.
> It is I think not controversial to say that forward is concerned with
> limiting
> the damage from end-point (especially server end-point) compromise, in
> which
> confidentiality of long-term keys (still held on the endpoint) is lost.
>

In the case of STEKs, the key may also be compromised without compromising
the endpoint. With multiple endpoints, there is usually some kind of
central STEK distribution system to synchronize the keys. And they key may
also be compromised due to weak crypto on the tickets themselves. So we
have to add those too to the threat model. But caches have similar
challenges, which might even be harder.


> Consider the fact that such compromise is unlikely to be detected and
> remediated
> instantaneously.  Indeed not only will the adversary have access for some
> time
> to sessions initiated post-compromise, he will also be able to impersonate
> the
> real server after the server is "secured" because certificate revocation
> will
> take days (or until the certificate expires) to take effect and more
> sessions
> can be compromised via MiTM attacks after the keys stolen.
>
> The incremental exposure of some fraction of a hour of sessions shortly
> before
> compromise pales in comparison with the much longer post-compromise
> exposure
> before the service is again secure.
>
> STEKs are simpler to design and secure than a complex session cache. This
> simplicity has security benefits.  Properly implemented STEKS have a
> lifetime
> that is much shorter than any plausible compromise exposure time window.
> Given
> this, it makes sense to not consider potential STEK compromise as loss of
> forward
> secrecy.
>
> Forward secrecy guards against disclosure of truly long-term key material,
> with
> a lifetime of weeks to years.  Once we get down to hours or minutes, it is
> quite
> sensible to take a coarser view of time, with similar exposure for sessions
> "just before" and "just after" compromise.
>
> Maximally sensitive traffic can take the penalty of avoiding session
> caching
> of any kind.
>

That does all makes sense, it just hasn't really been how TLS is deployed.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Viktor Dukhovni]

> On May 3, 2017, at 6:29 PM, Colm MacCárthaigh  wrote:
> 
> Pervasive forward secrecy is one of the central security goals of modern
> cryptography,

Sure, given a sensible definition of forward-secrecy.  And near instanenous
deletion of session keys is not part of such a definition.

> STEKs aren't compatible with this goal. They may be acceptable operationally
> today, but I think they must be borrowed time if the central goal is 
> meaningful.

We need to recall what thread-model is behind the desire for forward-secrecy.
It is I think not controversial to say that forward is concerned with limiting
the damage from end-point (especially server end-point) compromise, in which
confidentiality of long-term keys (still held on the endpoint) is lost.

Consider the fact that such compromise is unlikely to be detected and remediated
instantaneously.  Indeed not only will the adversary have access for some time
to sessions initiated post-compromise, he will also be able to impersonate the
real server after the server is "secured" because certificate revocation will
take days (or until the certificate expires) to take effect and more sessions
can be compromised via MiTM attacks after the keys stolen.

The incremental exposure of some fraction of a hour of sessions shortly before
compromise pales in comparison with the much longer post-compromise exposure
before the service is again secure.

STEKs are simpler to design and secure than a complex session cache. This
simplicity has security benefits.  Properly implemented STEKS have a lifetime
that is much shorter than any plausible compromise exposure time window.  Given
this, it makes sense to not consider potential STEK compromise as loss of 
forward
secrecy.

Forward secrecy guards against disclosure of truly long-term key material, with
a lifetime of weeks to years.  Once we get down to hours or minutes, it is quite
sensible to take a coarser view of time, with similar exposure for sessions
"just before" and "just after" compromise.

Maximally sensitive traffic can take the penalty of avoiding session caching
of any kind.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Wed, May 3, 2017 at 5:25 PM, Martin Thomson 
wrote:

> I was responding to an overly broad statement you made.  In the
> discussion you also talk about timing side-channels and other ways in
> which information can leak.  Nothing we do at the TLS layer will
> prevent those from being created in applications.
>

Sure, but things we're doing at the TLS layer can make it  much worse, as
in this case. I don't think we can make attacks easier.


> Also, it might pay to remember that this is part of a larger context.
> Applications routinely retry and replay; if they didn't, users would.
>

In the larger context, not all HTTP calls are coming from user actions, or
from clients that retry in that way. Some clients need to be careful,
precisely to achieve idempotency or safety. The review details the reasons
why, and also why it is impractical for actors to separate out these cases
and simple "not use" 0-RTT, due to how layers work and systems
interoperate.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Martin Thomson]

On 4 May 2017 at 09:16, Colm MacCárthaigh  wrote:
>> We've historically done a lot to
>> secure applications at a single point, and we're almost at the end of
>> what we can reasonably do for them at this layer.  We need to think
>> more hollistically and acknowledge that applications need to take some
>> responsibility for their own security.
>
> No we don't. Servers can prevent replay.

I was responding to an overly broad statement you made.  In the
discussion you also talk about timing side-channels and other ways in
which information can leak.  Nothing we do at the TLS layer will
prevent those from being created in applications.

Also, it might pay to remember that this is part of a larger context.
Applications routinely retry and replay; if they didn't, users would.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Viktor Dukhovni]

> On May 3, 2017, at 6:29 PM, Colm MacCárthaigh  wrote:
> 
> Just an aside related to that; it can be useful to fuzz ticket lifetimes a
> bit so all of the tickets from a STEK don't expire at exactly the same time.
> That can lead to a lot of painful renegotiations happening at once.

More than "a bit".  In Postfix session tickets have a constant lifetime 
regardless
of whether they were issued at the beginning of end of the current STEKs 
duration
is the STEK encryption key.  This works, because each STEK is retained as a
decryption-only key for a second "lifetime" while the next key is employed to
encrypt (and decrypt) new sessions.

There is no clustering of session expirations.  The plan is to do the same in
the default-on key rotation for OpenSSL.

-- 
Viktor.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh]

On Wed, May 3, 2017 at 3:56 PM, Martin Thomson 
wrote:

> On 3 May 2017 at 22:45, Colm MacCárthaigh  wrote:
> > This is easy to say; the TLS layer is the right place. It is not
> practical
> > for applications to defend themselves, especially from timing attacks.
>
> If you care about these attacks as much as it appears, then you can't
> reasonably take this position.


An analogy may help here. TLS has always offered anti-replay, it is one of
our core security guarantees, and the assumption that it is there is subtly
baked in to many applications.

Suppose we wanted to remove a different security guarantee: integrity
protection/tamper-proofing. Suppose we decided to offer a fast "No MAC"
mode for streamed uploads, it is faster, more stream-y (no need to wait for
each record to be complete), and TLS is really mostly about secrecy. But to
be "safe" we decide that it's only on optionally and sometimes, and we
always have to tell the application which data may have been tampered with.

The application can use its own MACing, or FECing, or whatever, and really
it should have been doing this from the days of plaintext HTTP, right!?
It's all the application's responsibility - we say, they can deal with it
[*]

Except MACing is hard, and they run in to Lucky13 all over again, or just
use MD5 because they don't know any better, and so on.  Or worst of all: a
middle box decides to enable it on the front-end, with no knowledge to the
backend about what's happening.

In my view, this arrangement would plainly be crazy. We wouldn't consider
it. Instead, we provide protection for them using layering principles, and
TLS provides protections that TLS experts are good at.

And yet we do consider all of this for replay. I think it's because
collectively we haven't seen just how hard a problem idempotency and
application-level side-effects are and we are less familiar with the risks.
In the review, I've included 5 real attacks to illustrate that problems are
real. Several of them I can't see how to mitigate them at application
level, and I've been checking with experts on distributed systems. How
would you mitigate the throttling problem (attack 3) or the timing problem
(attack 4) on say a JVM object cache?


> We've historically done a lot to
> secure applications at a single point, and we're almost at the end of
> what we can reasonably do for them at this layer.  We need to think
> more hollistically and acknowledge that applications need to take some
> responsibility for their own security.
>

No we don't. Servers can prevent replay.

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Martin Thomson]

On 3 May 2017 at 22:45, Colm MacCárthaigh  wrote:
> This is easy to say; the TLS layer is the right place. It is not practical
> for applications to defend themselves, especially from timing attacks.

If you care about these attacks as much as it appears, then you can't
reasonably take this position.  We've historically done a lot to
secure applications at a single point, and we're almost at the end of
what we can reasonably do for them at this layer.  We need to think
more hollistically and acknowledge that applications need to take some
responsibility for their own security.

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