Subject: [TLS] 0.5 RTT

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Feb 2016 11:27:10 -0800

Karthik raised some concerns here, and I think that we have some
thinking to do.  But I don't think that it is intractable, nor even
hard, to reason about this problem.

The only thing that the client's second flight provides is
authentication.  The Finished isn't needed if there is no client auth
[P].  Hugo's presentation at TRON did not include a client Finished in
the earlier, simpler examples.

Thus, based on Watson's observation that the client authentication is
removable, we might conclude that the handshake is complete from the
perspective of a server that does not require client authentication.
There are still reasons we might like to keep the client
authentication in the handshake, but those are decisions we can make
on engineering grounds.

If post-handshake client authentication is OK, then 0.5 RTT is equally
OK [X].  I would assert that any decision about changing keys after
the client Finished applies to post-handshake client auth (or vice
versa).

If that logic is sound, then I see no reason we can't have some very
simple advice:

  1. if the server does not request client authentication, it can send
application data immediately following its Finished

  2. if the server requests client authentication, it MUST NOT send
application data until it receives and validates the client's first
flight.  UNLESS the server is certain that the data it sends does not
depend on the client's identity (that is, it would send this
application data to anyone).

>From an API perspective, I believe that we should recommend that there
be a separate function for sending in condition 2, just as we are
going to recommend that there is a separate function for sending 0-RTT
data (as well as there being one to receive on the server end).

Based on this, we should recommend different points in time for the
server API to report that the handshake is "complete" at a server.  In
condition 1, the handshake is complete after the server Finished is
sent; in condition 2, the handshake is complete after the client
Finished is received.

[P] Note that a client Finished does confirm a PSK.  Though you might
reasonably argue that successfully generating valid application data
works equally well in that regard.
[X] Post-handshake client authentication has only been analyzed very
lightly, so we have to caveat that statement too.

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Tue, 23 Feb 2016 12:49:02 -0800

There are some fears about 0.5-RTT data that do not necessarily apply to post-client authentication, at which point at least both parties have sent their Finished messages.

When the server is sending 0.5-RTT data, this is effectively false-start;  the client hasn’t confirmed its choice of ciphersuites yet, and downgrade attacks may become possible.
To be principled, we should look at the current browser best practices for false start and  make sure that 0.5-RTT data abides by them.
For example, one may argue that 0.5-RTT is actually a bit worse than false-start in TLS 1.2  where at least the peer’s presence and DH key has been authenticated before false start data is sent. 
There is no such guarantee in 0.5-RTT.

The question is whether this is just a server-side concern, or does the client need to be aware of 0.5-RTT. 
I don’t know the answer to that, but if we wanted to setup a 0.5-RTT rule, I would say that it should *only*
be sent during PSK-resumption handshakes, because the PSK authenticates the peer, and because
the server is likely responding to some 0-RTT data sent by the client/

Again maybe this breaks some server push scenarios that I am not aware of.

Best,
Karthik

PS: The OPTLS proof does not require ClientFinished, but they do not consider downgrades or client auth. 
       On the whole, cryptographers including the authors of OPTLS would be happier with 0.5-RTT keys 
       not being the same as 1-RTT keys. Again, so far, this is a matter of taste and proof modularity.

> On 23 Feb 2016, at 11:27, Martin Thomson <[email-masked]> wrote:
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 23 Feb 2016 16:24:33 -0500

On Tue, Feb 23, 2016 at 3:49 PM, Karthikeyan Bhargavan <
[email-masked]> wrote:

> There are some fears about 0.5-RTT data that do not necessarily apply to
> post-client authentication, at which point at least both parties have sent
> their Finished messages.
>
> When the server is sending 0.5-RTT data, this is effectively false-start;
> the client hasn’t confirmed its choice of ciphersuites yet, and downgrade
> attacks may become possible.
> To be principled, we should look at the current browser best practices for
> false start and  make sure that 0.5-RTT data abides by them.
> For example, one may argue that 0.5-RTT is actually a bit worse than
> false-start in TLS 1.2  where at least the peer’s presence and DH key has
> been authenticated before false start data is sent.

​That's right, we do not consider downgrades or client authentication but
Martin's suggestion explicitly only applies to the case​ where the server
does not require client authentication so the analysis holds in that case.
As for downgrades, this will be discovered by the server when receiving the
client's Finished message. So the only problem I see is that the server
might have been "tricked" to send the 0.5-RTT data with less protection
than intended by the (honest) client. But for that there is no need for
downgrade. The attacker could have generated the exchange with the weaker
ciphersuite by himself (acting as a client). If the server accepts that
ciphersuite it means he is willing to send that particular data with that
level of security to *anyone*. That is the meaning of not requiring client
authentication.

​One useful feature of client's finished is to catch 0-RTT replays. But
even then I am not sure what damage can be done to the 0.5 data. Either the
attacker knows the client's keying material (say PSK) and can generate the
client finished by himself or he doesn't know that keying material but then
it cannot decrypt 0.5 data.

Am I missing something on these particular points?

       On the whole, cryptographers including the authors of OPTLS would be
> happier with 0.5-RTT keys

​Agreed.

Hugo

​

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Feb 2016 13:38:57 -0800

On 23 February 2016 at 13:24, Hugo Krawczyk <[email-masked]> wrote:
> client's Finished message.

Won't a downgrade be detected by the client when it fails to decrypt
the server's data?  If the server was given a false impression about
the client's capabilities, then that can only happen if it receives a
different ClientHello to the one the client sent.

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Tue, 23 Feb 2016 13:58:30 -0800

> ​That's right, we do not consider downgrades or client authentication but Martin's suggestion explicitly only applies to the case​ where the server does not require client authentication so the analysis holds in that case. As for downgrades, this will be discovered by the server when receiving the client's Finished message. So the only problem I see is that the server might have been "tricked" to send the 0.5-RTT data with less protection than intended by the (honest) client. But for that there is no need for downgrade. The attacker could have generated the exchange with the weaker ciphersuite by himself (acting as a client). If the server accepts that ciphersuite it means he is willing to send that particular data with that level of security to *anyone*. That is the meaning of not requiring client authentication. 

Yes Hugo, you’re right that when there is no client auth, the situation is less problematic. 

However, let’s note there may still be implicit kind of authentication, for example, what if the client hello requests PSK-based 1-RTT with a old-broken cipher that the real client would never use.
The server should not, in this case, send user-specific data under the old-broken cipher until it receives the client finished.
Of course, this could be worked around by having a nice whitelist of ciphers, or possibly other designs.
I am mainly pointing out that we need to be careful that the guarantees for 0.5-RTT seem to be strictly weaker than that for 1-RTT.

> ​One useful feature of client's finished is to catch 0-RTT replays. But even then I am not sure what damage can be done to the 0.5 data. Either the attacker knows the client's keying material (say PSK) and can generate the client finished by himself or he doesn't know that keying material but then it cannot decrypt 0.5 data.

Right, this is the other concern. Suppose a passive adversary records a clients 0-RTT data (under a PSK that is bound to an authenticated client).
He can then go home and replay this 0-RTT request as many times as he wants and record the server’s 0.5-RTT responses. 
They will be encrypted, sure, but maybe even the length of those responses may give the attacker useful dynamic information (e.g. he can tell whether the user’s bank balance went up or down by a digit). 

Yes, this attack is always possible for a persistent passive adversary, and we can mitigate it with length-hiding techniques, but it gives us an example of how 0.5-RTT may provide new avenues for attacking encrypted connections.

Best,
Karthik

> > On 23 Feb 2016, at 11:27, Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Tue, 23 Feb 2016 14:01:28 -0800

> the server's data? 

The main downgrade concern, I think, is for the 0.5-RTT data’s confidentiality; i.e. it may have been sent encrypted under a broken cipher.
You’re right that the client will not accept this data because the handshake hashes (mixed into the key) would not match.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Feb 2016 14:08:21 -0800

> The main downgrade concern, I think, is for the 0.5-RTT data’s confidentiality; i.e. it may have been sent encrypted under a broken cipher.

Hmm, that's a good point.  So Antoine's analogy is closer to correct
than I had thought, and the need for Finished remains.

There's an argument that says that 0.5RTT data isn't confidential
because the server would send it to anyone, but I don't agree with
that viewpoint.  And we're potentially also handling 0-RTT data before
sending 0.5 data.

Like I said on the weekend, we don't have to solve every problem.
None of the cipher suites in TLS 1.3 would fail to qualify as broken
currently, but if they did, then logic similar to what we recommend
for false start seems reasonable to me.  Other than that, we can
simply document the shortcoming.  I don't think that any of this
justifies a stronger response than that, and that includes extra key
updates.

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 23 Feb 2016 17:26:17 -0500

Karthik, I think that what you are pointing to are cases where the client
*is* authenticated via its PSK.

There is an important distinction between PSKs that have been authenticated
by the client (in a previous exchange) and those that are not.
Any PSK-based handshake that uses a (previously) client-authenticated PSK
needs to be treated as client-authenticated and replay needs to be dealt
with utmost care, including the need to validate via the client finished
that the current exchange is not a replay. In the case where the PSK is
client-unauthenticated (e.g. a resumption from a server-only authenticated
handshake) and the server does not request client authentication then the
need for client finished is less crucial.

Let me be clear, I prefer a conservative design to a more liberal one so if
we can do without 0.5 data then much better.

Hugo

On Tue, Feb 23, 2016 at 4:58 PM, Karthikeyan Bhargavan <
[email-masked]> wrote:

> However, let’s note there may still be implicit kind of authentication,
> for example, what if the client hello requests PSK-based 1-RTT with a
> old-broken cipher that the real client would never use.
> The server should not, in this case, send user-specific data under the
> old-broken cipher until it receives the client finished.
> I am mainly pointing out that we need to be careful that the guarantees
> for 0.5-RTT seem to be strictly weaker than that for 1-RTT.
>
>
> Right, this is the other concern. Suppose a passive adversary records a
> clients 0-RTT data (under a PSK that is bound to an authenticated client).
> He can then go home and replay this 0-RTT request as many times as he
> wants and record the server’s 0.5-RTT responses.
> They will be encrypted, sure, but maybe even the length of those responses
> may give the attacker useful dynamic information (e.g. he can tell whether
> the user’s bank balance went up or down by a digit).
>
> Yes, this attack is always possible for a persistent passive adversary,
> and we can mitigate it with length-hiding techniques, but it gives us an
> example of how 0.5-RTT may provide new avenues for attacking encrypted
> connections.
>
> Best,
> Karthik
>
>
>

---

From: Watson Ladd <[email-masked]>
Date: Tue, 23 Feb 2016 14:32:17 -0800

>
> There is an important distinction between PSKs that have been
authenticated by the client (in a previous exchange) and those that are not.

Authentication is also handled at a higher layer through HTTP cookies or
token binding. We need to ensure our analysis covers these interactions.

>
> Let me be clear, I prefer a conservative design to a more liberal one so
if we can do without 0.5 data then much better.

I think we should seperate a conservative TLS 1.3 core consisting only of
those features we are absolutely certain function together well, with RSA
endpoint cert signatures banned, and no 0-RTT, and encourage implementors
to make it easy to restrict to this subset.

>From TRON my impressesion is that this includes 1-RTT exchanges and so is
already a latency gain over existing TLS.

[email-masked]> wrote:
>>>
>>> ​That's right, we do not consider downgrades or client authentication
but Martin's suggestion explicitly only applies to the case​ where the
server does not require client authentication so the analysis holds in that
case. As for downgrades, this will be discovered by the server when
receiving the client's Finished message. So the only problem I see is that
the server might have been "tricked" to send the 0.5-RTT data with less
protection than intended by the (honest) client. But for that there is no
need for downgrade. The attacker could have generated the exchange with the
weaker ciphersuite by himself (acting as a client). If the server accepts
that ciphersuite it means he is willing to send that particular data with
that level of security to *anyone*. That is the meaning of not requiring
client authentication.
>> They will be encrypted, sure, but maybe even the length of those
responses may give the attacker useful dynamic information (e.g. he can
tell whether the user’s bank balance went up or down by a digit).

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Tue, 23 Feb 2016 14:32:38 -0800

> Any PSK-based handshake that uses a (previously) client-authenticated PSK needs to be treated as client-authenticated and replay needs to be dealt with utmost care, including the need to validate via the client finished that the current exchange is not a replay. In the case where the PSK is client-unauthenticated (e.g. a resumption from a server-only authenticated handshake) and the server does not request client authentication then the need for client finished is less crucial.

Hugo, I think you and I are mostly agreeing on these concerns.
I will point out that there are other ways of authenticating than certificate and PSK-based auth that are not necessarily visible to TLS.
For example, the application may have used the exporter master secret in the previous session to authenticate the user 
Or, more simply, the replayed 0-RTT request may contain a cookie.

> 
> Let me be clear, I prefer a conservative design to a more liberal one so if we can do without 0.5 data then much better. 
> 
> Hugo
> 
> 
> 
> 
> On Tue, Feb 23, 2016 at 4:58 PM, Karthikeyan Bhargavan <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Feb 2016 14:33:00 -0800

> *is* authenticated via its PSK.

In the downgrade scenario, that doesn't seem right, but maybe it's
just that the client's ClientHello is being authenticated.

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 23 Feb 2016 17:37:45 -0500

On Tue, Feb 23, 2016 at 5:08 PM, Martin Thomson <[email-masked]>
wrote:

> > The main downgrade concern, I think, is for the 0.5-RTT data’s
> confidentiality; i.e. it may have been sent encrypted under a broken cipher.
>
> that viewpoint.

​I would be interested to hear why you don't agree with that viewpoint.
It seems to imply that you are attaching some "client-specific semantics"
even to keys that were not authenticated by the client.
Understanding such semantics would be a good guide for when 0.5 data may be
safe.

​But the truth is that whatever these semantics are, under your above
viewpoint you should never send 0.5 data.​
​Matching vague semantics to cryptographic security is too hard a problem
to get it right.

(In particular, if these semantics may be based on stuff that happens
outside TLS, as Karthik and Watson were pointing out, then maybe we really
put a "Surgeon General" warning on 0.5 data of equal size to that of 0-RTT.)

Hugo​

And we're potentially also handling 0-RTT data before

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Feb 2016 14:52:00 -0800

> even to keys that were not authenticated by the client.

It's primarily a privacy concern, though it's a pretty weak concern.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Feb 2016 01:49:16 +0000

> put a "Surgeon General" warning on 0.5 data of equal size to that of 0-RTT.)

That, and/or also do a significant amount of work to consider other
application uses of TLS that aren't well represented by folks who
participate in the development of TLS1.3. And also oddities like
EAP-TLS about which I at least am mostly ignorant but where I'd bet
there's "fun" to be had with 0rtt.

And we have to do that recognising that regardless of what the RFC
says, if developers can improve performance by calling tls_send0()
and not tls_send(), they will do the former. IOW, if we are going
to define dangerous implements, (e.g., with replayable data) then
I think the onus is mostly on us to know what bad effects those
might have before we've done a good job. (We can try do that at
IETF LC, but doing so isn't common and is often messy if we end up
surprising folks.)

Cheers,
S.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 23 Feb 2016 19:28:12 -0800

> there's "fun" to be had with 0rtt.

Applications shouldn't use 0RTT unless they are absolutely,
positively, sure it won't be a problem. It's up to them to determine
what the danger is, and up to us to explain what the (minimal)
properties provided are. If they rely on extensions then either those
extensions need to be included in the security proofs, or we need to
make clear that they are not as secure as TLS 1.3, and that
implementations which enable both of them can get completely wrecked
in new and exciting ways.

> IETF LC, but doing so isn't common and is often messy if we end up

But will they call tls_send_data_replayable? or
tls_send_data_dangerously? API designers need to mark dangerous
functions accordingly. (They also need to make APIs easy to use: yes,
I am blaming the OpenSSL developers for their repeated and continued
failures to do this)

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

---

From: [email-masked]
Date: Wed, 24 Feb 2016 03:36:03 +0000

On Tue Feb 23 19:28:12 2016 GMT-0800, Watson Ladd wrote:
> tls_send_data_dangerously?

Sadly, yes, they will, I think. Evidence welcome though. 

It is a big and imperfect world.

S.

> API designers need to mark dangerous

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 23 Feb 2016 22:48:15 -0500

I was trying to articulate what does the analysis in OPTLS that does not
include the client's Finished message (or client authentication) means in
practical terms for 0.5-RTT data. I think that one way to put it is that
for the server it guarantees confidentiality against passive (only)
attackers and for the client it provides data authentication (proof of
origin and integrity).

Note that  confidentiality against passive attackers is the same type of
assurance we provide to the encrypted server's identity. The same way a
server needs to "understand" that any active attacker can learn its
identity from a TLS handshake, it also needs to understand that 0.5 data is
open to any active attacker. Any expectations of 0.5 data being directed to
a specific client need to be eliminated.

Hugo

---

From: [email-masked] (Martin Rex)
Date: Thu, 25 Feb 2016 13:29:54 +0100 (CET)

Karthikeyan Bhargavan wrote:
> 
> Yes Hugo, you?re right that when there is no client auth,
> the situation is less problematic. 

I'm not so sure.

There might be the desire of the server to keep some data confidential,
and your argument is that if the data wasn't confidential to begin with,
the server is not "breaking" confidentiality--although the server is
clearly doing this.

But what about the client and the client's desire to keep confidential,
which particular "public data" it is just requesting and receiving
from the server.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Thu, 25 Feb 2016 13:40:42 +0100 (CET)

Watson Ladd wrote:
> 
> But will they call tls_send_data_replayable?

The proper name would be tls_send_data_replayable_and_NO_forward_secrecy.

-Martin

---

From: Antoine Delignat-Lavaud <[email-masked]>
Date: Thu, 25 Feb 2016 13:55:27 +0000

>> the situation is less problematic.

QUIC gives a pretty good idea of how 0-RTT is going to be used in 
browsers: they will almost certainly send 0-RTT requests that contain 
session cookies and servers will return confidential data in 0.5-RTT 
routinely. I think it is very important to assume that this usage 
scenario is part of the core features of 1.3 that we model and analyze.

There is little doubt that 0.5-RTT will leak some bits of information 
due to replayability; nevertheless, assuming that 0.5-RTT data is always 
public and give it the same guarantees as handshake encryption is a bad 
way to deal with these problems.

Under the current key schedule, an active adversary still needs to break 
the PSK in order to decrypt 0.5-RTT data; this is a forward secrecy 
problem rather than a confidentiality one.

Even if the 0-RTT finished message is removed, the context of the 0-RTT 
data key will still include the current ClientHello, and thus, downgrade 
in the style of Logjam+False Start requires PSK compromise as well.

Concerning agility, a simple strategy is to pre-negotiate 0-RTT 
handshake parameters (including ciphersuite) when the PSK is established 
(i.e. extend the NewSessionTicket message).

Best,

Antoine

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 25 Feb 2016 14:54:04 -0500

As I said in another email, without client authentication (which is the
scenario in the Karthik quote), data sent by the server should be
considered secure only against passive adversaries. Any additional
assumption on confidentiality (i.e., restricting the power of an active
attacker) must consider some form of client authentication, either implicit
or explicit. Both cases must be dealt with with care, especially the
implicit ones (e.g. authentication implied by application mechanisms and
semantics).

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Feb 2016 04:46:48 +0800

On Thu, Feb 25, 2016 at 9:55 PM, Antoine Delignat-Lavaud <
[email-masked]> wrote:

> routinely. I think it is very important to assume that this usage scenario
> is part of the core features of 1.3 that we model and analyze.
>

Yes, that's correct.

> There is little doubt that 0.5-RTT will leak some bits of information due
> to replayability; nevertheless, assuming that 0.5-RTT data is always public
> and give it the same guarantees as handshake encryption is a bad way to
> deal with these problems.
>
> the PSK in order to decrypt 0.5-RTT data; this is a forward secrecy problem
> rather than a confidentiality one.
>
> data key will still include the current ClientHello, and thus, downgrade in
> the style of Logjam+False Start requires PSK compromise as well.
>
> Concerning agility, a simple strategy is to pre-negotiate 0-RTT handshake
> parameters (including ciphersuite) when the PSK is established (i.e. extend
> the NewSessionTicket message).
>

My thought of how to deal with this was to simply *infer* the 0-RTT
parameters
from those when the PSK was established. This is the natural extension of
what
the document currently says about DHE-0RTT but can be simpler because
the ticket can contain the full state.

-Ekr

---

From: Watson Ladd <[email-masked]>
Date: Thu, 25 Feb 2016 19:20:46 -0800

On Thu, Feb 25, 2016 at 11:54 AM, Hugo Krawczyk <[email-masked]> wrote:
> scenario in the Karthik quote), data sent by the server should be considered
> secure only against passive adversaries. Any additional assumption on
> confidentiality (i.e., restricting the power of an active attacker) must
> consider some form of client authentication, either implicit or explicit.
> Both cases must be dealt with with care, especially the implicit ones (e.g.
> authentication implied by application mechanisms and semantics).

I think this is unnecessarily pessimistic/ignores the ways in which
higher-level applications may have authentication and what we need
from them. The below should be taken as a clever guess, rather than
representative of the truth.

First, we know that negotiation doesn't work in 0-RTT. But that's ok:
we need to limit to only strong ciphers anyway, because negotiation
doesn't work/general depreciation. This means that clients can be
fooled by attackers into using the weakest notion they support for
continued authentication of PSKs: this applies to resumption with
tickets as well.

We also know that each PSK is only shared between one server and one
other client from the unpredictability of the negotiated keys. And so
when when a server decrypts a ticket, it knows that whatever data it
saved in the ticket negotiated in the original negotiation applies to
whoever sent it this 0-RTT data, and it knows its response will go
only to someone who *at one point* sent this 0-RTT data. And so if
there is a cookie or url parameter authenticating the client that is
not tied to the PSK, so long as the PSK is secure there is only one
party that could have sent that cookie, and the response will go to
it. The same is true for prior client authentication, saved in the
ticket.

Formalizing the above is likely to be a bit tricky, but I don't see
why it wouldn't be possible.

---

From: Hugo Krawczyk <[email-masked]>
Date: Fri, 26 Feb 2016 19:41:12 -0500

On Thu, Feb 25, 2016 at 10:20 PM, Watson Ladd <[email-masked]> wrote:

> considered
> from them.

​It is not pessimistic - it says that you either assume some form of client
authentication verified by the server, implicitly or explicitly, or
otherwise the server can only treat its 0.5 data as open to active attacks.
​

> The below should be taken as a clever guess, rather than

​You know that these intuitive argument *almost* always work.
Problem is that all attacks are hiding behind the "almost" part ;-)

I am not saying that something like this cannot be formalized, but it will
not be easy, particularly since the ways of authentication are varied and
depend on applications and semantics that are hard to reason about, let
alone formalize mathematically.

People can and will build on such assumptions but they should do that with
a lot of care and with as much mathematical analysis behind it as possible.

Hugo
​