Subject: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

From: Cas Cremers <[email-masked]>
Date: Fri, 10 Feb 2017 12:43:56 +0000

Dear all,

In the process of completing our Tamarin analysis of TLS 1.3 revision 18,
we hit upon some behaviour that may lead to applications making incorrect
assumptions. It is not an immediate attack, but we can imagine scenarios
where it can cause problems. We describe it below, and show that it is
possible to adapt the protocol (leveraging existing mechanisms) to avoid a
mismatch.

Currently, the post-handshake client authentication does not cause updates
to the transcript, and does not necessarily trigger key updates. As a
result, the post-handshake client authentication offers substantially lower
guarantees *for the client* than the normal mutual authentication. To see
why this is the case, consider the following two properties that hold for
the mutually authenticated handshake:

(A) After the mutually authenticated handshake, a client who sends some
data can be sure that if the server receives it, the server will be aware
that it comes from an authenticated client.

(B) After the mutually authenticated handshake, a client who receives some
data can be sure that when the server sent it, the server was aware that it
was sending it to an authenticated client. (Formally: upon receiving data,
the client has agreement with the server on the status (unilateral/mutual)
of the connection.)

>From our analysis we have concluded that no such properties hold for the
post-handshake client authentication. The reason is that the post-handshake
client authentication does not change the transcript, and does not trigger
a key update: effectively, the server has no way of informing the client
that it has actually processed the post-handshake client authentication.
Thus, the client will get identical future messages, irrespective of
whether the server received the client authentication.

Generally speaking, a unilaterally authenticated connection should have a
different context, and therefore different keys, than a mutually
authenticated connection. Currently, this is not the case for the
post-handshake authentication.

Potential problem scenario

Assume that the server has two security policies: if a message is received
from an authenticated client, it is marked as "top secret" and stored
safely. If a message is received from an unauthenticated client, it is
stored in plaintext or even published in a log. After a mutual
authentication handshake, if the client sends some critical data then it
can be sure this is stored securely.

However, this is not the case for a post-handshake client authentication.
After performing a post-handshake authentication (in which the client sends
its certificate), and possibly after exchanging further messages with the
server, the client may send some critical data. This data may be stored
insecurely as there will be a mismatch between the client and server’s
respective views of authentication if the post-handshake authentication
messages are not processed by the server and/or dropped by an attacker.

Option 1: Fix

In our view, the unilateral/mutual authentication status should be part of
the context, and thus correspond to different keys. We are aware that the
server’s request for post-handshake authentication is desired to be
asynchronous (since user input might be needed). The most natural fix to
the problem therefore is to include the client's response authentication
messages (certificate etc.) in the message transcript, and require key
updates.

Option 2: Partial fix

It is also possible to simply update the keys, leaving the transcript as
is. This allows the client to infer whether his authentication message was
received. However it does still allow for re-ordering of some messages.
This has the disadvantage that the client certificate is still not included
in the context, which may be problematic further down the line.

Option 3: Don’t fix (“Somebody Else’s Problem shield”)

If we do not change the protocol, the draft should be updated to explicitly
state that after a post-handshake authentication, the client can make no
assumptions on the authentication status of the connection (mutual or
unilateral). If the client would like to know the perceived status, it
could ask the application layer. We do not advocate this solution, since
the resulting difference between the guarantees of a regular mutually
authenticated handshake and a post-handshake client authentication will
surely lead to problems somewhere, and client applications will wrongly
assume that after they send the post-handshake certificate, the server is
aware that the connection is mutually authenticated.

Tamarin analysis

Using Tamarin, we showed that the properties (A) and (B) hold for the
normal mutually authenticated handshake. We also showed that similar
properties do not hold after the post-handshake client authentication, and
we obtain the obvious counter-examples. If we apply the partial fix (2),
the counter-examples indeed disappear.

Conclusion

In revision 18, the client can not be sure that the server agrees on the
client’s authentication status after post-handshake authentication, even
after exchanging further messages.

To avoid problems at the application level, we would prefer this agreement
to be ensured.

Best wishes,

Cas Cremers,

Marko Horvat,

Jonathan Hoyland,

Sam Scott, and

Thyla van der Merwe.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 10 Feb 2017 19:22:24 +0200

> possible to adapt the protocol (leveraging existing mechanisms) to avoid a

Ah, Post-HS auth, one of the two things in TLS 1.3 that scare me. :-)

> that it comes from an authenticated client.

AFAICT, this fails even for TLS 1.3 in-handshake authentication.

> the client has agreement with the server on the status (unilateral/mutual)

And this too (failure of (A) already impiles this fails).

> messages are not processed by the server and/or dropped by an attacker.

In TLS, the messages can't be dropped without tearing the entiere client-
server link, but the server may indeed fail to process them.

DTLS is another can of worms.
 
> messages (certificate etc.) in the message transcript, and require key

This would require ACK/NAK for the authentication and restricting server
to just one pending authentication in order to properly serialize the
message order.

And ACK/NAK is needed because otherwise this AFAICT won't solve the
problem. And if you have the ACK/NAK, that should take care of the
problem in cases not involving weak algorithms.

> in the context, which may be problematic further down the line.

I don't see how this helps: The client already knows its authentication
block was delivered before any further data it sent. What it doesn't know
is if the server acted on it.
 
> aware that the connection is mutually authenticated.

AFICT, This isn't just for post-handshake authentication. And also, the
TLS stack has pretty limited view. It can't realistically assumed to
know the actual authentication status of the connection.

-Ilari

---

From: Sam Scott <[email-masked]>
Date: Fri, 10 Feb 2017 19:45:58 +0000

Hi Ilari,

Thanks for the comments.

Assuming the client sends a valid certificate that the server accepts, 
then the server cannot finish the handshake or begin processing incoming 
application data until authenticating the client. This *almost* gives us 
property (A). In practice, the client is aware that the server has 
successfully authenticated since the protocol continues.

In the case that the server has implemented the reject option (rejecting 
a certificate but still continuing), and indeed rejects the certificate, 
then the server should send an alert message (or NAK of some form) for 
the property to hold in the initial handshake.

However, even if we take the certificate reject + continue scenario into 
account for the initial handshake, then it is clear that this decision 
can only be made by the server in the initial handshake, while in the 
post-handshake client auth, an attacker can decide this (by dropping the 
message).

The reason we don't believe an explicit ACK is needed is because 
upgrading to a new pair of keys explicitly provides this. Specifically, 
the client will send all subsequent data to the server under a new key. 
The server will not be able to decrypt this data until they receive the 
client authentication messages and upgrade the keys.

This can be strengthened if the client's updated write key is computed 
using the authentication messages.

We agree that TLS enforcing ordering of messages provides similar 
guarantees. However, we are analysing the specification as it is 
presented, which does not guarantee this.

Thanks,

Sam

---

From: Andrei Popov <[email-masked]>
Date: Fri, 10 Feb 2017 19:54:30 +0000

Hi Sam,

This part is not clear to me:
> ...while in the post-handshake client auth, an attacker can decide this (by dropping the message).

How does the attacker drop a TLS-protected message without terminating the connection?

Thanks,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Sam Scott
Sent: Friday, February 10, 2017 11:46 AM
To: Ilari Liusvaara <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

Hi Ilari,

Thanks for the comments.

Assuming the client sends a valid certificate that the server accepts, then the server cannot finish the handshake or begin processing incoming application data until authenticating the client. This *almost* gives us property (A). In practice, the client is aware that the server has successfully authenticated since the protocol continues.

In the case that the server has implemented the reject option (rejecting a certificate but still continuing), and indeed rejects the certificate, then the server should send an alert message (or NAK of some form) for the property to hold in the initial handshake.

However, even if we take the certificate reject + continue scenario into account for the initial handshake, then it is clear that this decision can only be made by the server in the initial handshake, while in the post-handshake client auth, an attacker can decide this (by dropping the message).

The reason we don't believe an explicit ACK is needed is because upgrading to a new pair of keys explicitly provides this. Specifically, the client will send all subsequent data to the server under a new key. 
The server will not be able to decrypt this data until they receive the client authentication messages and upgrade the keys.

This can be strengthened if the client's updated write key is computed using the authentication messages.

We agree that TLS enforcing ordering of messages provides similar guarantees. However, we are analysing the specification as it is presented, which does not guarantee this.

Thanks,

Sam

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Sam Scott <[email-masked]>
Date: Fri, 10 Feb 2017 20:31:08 +0000

Hi all,

Thanks Ilari and Andrei for pointing towards the fact that TLS 
guarantees ordering of messages.

On closer inspection, this has a similar effect as our partial fix to 
ensure the server must process the authentication message before continuing.

We still consider the lack of a strict binding by not including the 
client certificate in the transcript to be a slight problem, but this is 
less of an issue than what we first discovered. Our model assumes 
messages can arrive out of order, so perhaps we are instead considering 
a weaker variant, similar to DTLS.

The core observation remains that the context does not change when going 
from unilateral to mutual, which seems counter to the intuition of the 
context. We would prefer the context to also contain the client cert in 
mutual authentication. Indeed, we first encountered this issue when 
considering whether the client/server would agree on the authentication 
status after a session resumption. In this case, the client auth and 
NewSessionTicket messages may cross over which would result in a similar 
mismatch.

Thanks,

Sam

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Feb 2017 12:39:03 -0800

Cas, Sam,

I thought I understood your concern here but maybe I don't.

Say we have the following sequence of messages

  1. C->S: ClientHello
  2. S->C: ServerHello...ServerFinished
  3. C->S: ClientFinished
  4. C->S: App message
  5. S->C: App message
  6. S->C: CertificateRequest
  7: C->S: Certificate...Finished
  8: C->S: App message
  9: S->C: App message

As you indicate, there's some ambiguity from the client's perspective
(property B) about whether messages 5 and 9 were sent by the server
prior to or after receiving message 7, and also message 8. This
ambiguity exists even without an attacker and may or may not be
resolved at the application layer. An attacker can exploit this
ambiguity by holding messages 7 and 8 and (as long as application
semantics permit this).

Where I get confused is about property A. As I understand your
claim, an attacker can hold message 7 but deliver message 8 and
therefore, even if the client knows that 9 was in response to 8,
he doesn't know that the server received 7. As Ilari says, I don't
believe that this is correct because TLS enforces message ordering.
I agree that the specification doesn't explicitly say this, but
it's implicit in the processing rules via the following:

1. The encryption for each TLS record depends on the record sequence
   number (RSN).
2. Records do not carry their RSN, so when you decrypt a message, you
   must use the last RSN + 1
3. When you fail to decrypt a message (which is what happens if you have
   the wrong RSN) you are required to tear down the connection
   (https://tlswg.github.io/tls13-spec/#record-payload-protection).

For this reason, if the attacker removes message 7, then 8 will not
be decryptable, and so ordering is preserved. As Ilari says, this isn't
true in DTLS 1.3 which we'll presumably have to deal with one way
or the other before standardization (my plan would be just to forbid
post-handshake auth). Do you disagree with this? If so, perhaps you
could explain.

-Ekr

P.S. I am not sure that the regular TLS handshake guarantees these
properties either. The reason is that the server is permitted to
send data prior to receiving the client's second flight (0.5 RTT
data). See:
https://tlswg.github.io/tls13-spec/#protocol-overview

On Fri, Feb 10, 2017 at 11:45 AM, Sam Scott <[email-masked]> wrote:

> In the case that the server has implemented the reject option (rejecting a
> certificate but still continuing), and indeed rejects the certificate, then
> the server should send an alert message (or NAK of some form) for the
> property to hold in the initial handshake.
>
> account for the initial handshake, then it is clear that this decision can
> only be made by the server in the initial handshake, while in the
> The reason we don't believe an explicit ACK is needed is because upgrading
> to a new pair of keys explicitly provides this. Specifically, the client
> will send all subsequent data to the server under a new key. The server
> will not be able to decrypt this data until they receive the client
> authentication messages and upgrade the keys.
>
> guarantees. However, we are analysing the specification as it is presented,
> which does not guarantee this.
>
> Thanks,
>
> Sam
>
>

---

From: Victor Vasiliev <[email-masked]>
Date: Fri, 10 Feb 2017 15:44:35 -0500

> it's implicit in the processing rules via the following:

We do at least explicitly promise those properties in Section E.2:

Order protection/non-replayability
: An attacker should not be able to cause the receiver to accept a
record which it has already accepted or cause the receiver to accept
record N+1 without having first processed record N.

  -- Victor.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Feb 2017 12:51:08 -0800

> record N+1 without having first processed record N.
Good point, so if the processing rules don't in fact enforce that, we
should make them
do so (I think they do for the reasons I indicated earlier)

-Ekr

---

From: Sam Scott <[email-masked]>
Date: Fri, 10 Feb 2017 20:52:53 +0000

Hi Ekr,

That's a good summary of the situation. Indeed we weren't previously 
considering TLS as able to enforce the ordering of messages which does 
seem to mitigate our scenario for property A. We haven't really had a 
chance to take that into consideration for property B, but at a glance 
it does still seem to be an issue.

As mentioned in my other email, one scenario we encountered this was if 
(using your message numbering as reference) messages 5 or 9 happened to 
be a NewSessionTicket. In this case, the client might be under the 
impression that they have a session ticket for a mutually authenticated 
channel.

Thanks,

Sam

On 10/02/17 20:39, Eric Rescorla wrote:
>    (https://tlswg.github.io/tls13-spec/#record-payload-protection 
> <https://tlswg.github.io/tls13-spec/#record-payload-protection>).
>
> <https://tlswg.github.io/tls13-spec/#protocol-overview>
>
>
>
>
>
> On Fri, Feb 10, 2017 at 11:45 AM, Sam Scott <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Ilari,
>
>     Thanks for the comments.
>
>     Assuming the client sends a valid certificate that the server
>     accepts, then the server cannot finish the handshake or begin
>     processing incoming application data until authenticating the
>     client. This *almost* gives us property (A). In practice, the
>     client is aware that the server has successfully authenticated
>     since the protocol continues.
>
>     In the case that the server has implemented the reject option
>     (rejecting a certificate but still continuing), and indeed rejects
>     the certificate, then the server should send an alert message (or
>     NAK of some form) for the property to hold in the initial handshake.
>
>     However, even if we take the certificate reject + continue
>     scenario into account for the initial handshake, then it is clear
>     that this decision can only be made by the server in the initial
>     handshake, while in the post-handshake client auth, an attacker
>     can decide this (by dropping the message).
>
>     upgrading to a new pair of keys explicitly provides this.
>     Specifically, the client will send all subsequent data to the
>     server under a new key. The server will not be able to decrypt
>     this data until they receive the client authentication messages
>     and upgrade the keys.
>
>     This can be strengthened if the client's updated write key is
>     computed using the authentication messages.
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tls>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Feb 2017 12:55:58 -0800

On Fri, Feb 10, 2017 at 12:52 PM, Sam Scott <[email-masked]> wrote:

> considering TLS as able to enforce the ordering of messages which does seem
> to mitigate our scenario for property A. We haven't really had a chance to
> take that into consideration for property B, but at a glance it does still
> seem to be an issue.
>

I agree. It doesn't mitigate B at all unless there are application
semantics that do so (which is the same
as it doesn't mitigate it, I guess).

> (using your message numbering as reference) messages 5 or 9 happened to be
> a NewSessionTicket. In this case, the client might be under the impression
> that they have a session ticket for a mutually authenticated channel.
>

Yes, I agree with this.

-Ekr

>> then the server should send an alert message (or NAK of some form) for the
>> upgrading to a new pair of keys explicitly provides this. Specifically, the
>> client will send all subsequent data to the server under a new key. The
>> server will not be able to decrypt this data until they receive the client

---

From: Andrei Popov <[email-masked]>
Date: Sat, 11 Feb 2017 01:49:17 +0000

What about Eric’s other point:

Ø  I am not sure that the regular TLS handshake guarantees these

Ø  properties either. The reason is that the server is permitted to

Ø  send data prior to receiving the client's second flight (0.5 RTT

Ø  data).

With the server sending data prior to receiving the client’s second flight, it seems that property B is not there when using in-handshake client authentication as well?

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Sam Scott
Sent: Friday, February 10, 2017 12:53 PM
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

Hi Ekr,

That's a good summary of the situation. Indeed we weren't previously considering TLS as able to enforce the ordering of messages which does seem to mitigate our scenario for property A. We haven't really had a chance to take that into consideration for property B, but at a glance it does still seem to be an issue.

As mentioned in my other email, one scenario we encountered this was if (using your message numbering as reference) messages 5 or 9 happened to be a NewSessionTicket. In this case, the client might be under the impression that they have a session ticket for a mutually authenticated channel.

Thanks,

Sam

  1. C->S: ClientHello

-Ekr

On Fri, Feb 10, 2017 at 11:45 AM, Sam Scott <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ilari,

Thanks for the comments.

The reason we don't believe an explicit ACK is needed is because upgrading to a new pair of keys explicitly provides this. Specifically, the client will send all subsequent data to the server under a new key. The server will not be able to decrypt this data until they receive the client authentication messages and upgrade the keys.

Thanks,

Sam

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: Sam Scott <[email-masked]>
Date: Sat, 11 Feb 2017 14:52:53 +0000

Is it common that 0.5 RTT data will be sent by the server in a fresh 
session? I.e. not after a resumption and therefore without the client 
previously sending early data?

Even so, it does also seem like a slightly troubling scenario, since the 
client has no (in-band) mechanism to determine the authentication was 
successful (or even at what point it arrived). Again, this could be 
rectified by forcing the client/server to update their keys, and even 
better if they include the client's authentication messages.

However, NewSessionTicket messages do not have this problem since the 
server wont send these before processing the client Finished, but it 
could still be an issue in the post-hs scenario.

Just want to reiterate: thanks all for helping to clarify this behaviour 
we've encountered. Hopefully it proves a useful insight into the 
guarantees (or lack thereof) provided  by client authentication. Also it 
is really useful in helping us to refine our model :)

Sam

On 11/02/17 01:49, Andrei Popov wrote:
> ØI am not sure that the regular TLS handshake guarantees these
>
> Øproperties either. The reason is that the server is permitted to
>
> Øsend data prior to receiving the client's second flight (0.5 RTT
>
> Ødata).
>
> With the server sending data prior to receiving the client’s second 
> flight, it seems that property B is not there when using in-handshake 
> client authentication as well?
>
> Cheers,
>
> Andrei
>
> *From:*TLS [mailto:[email-masked]] *On Behalf Of *Sam Scott
> *Sent:* Friday, February 10, 2017 12:53 PM
> *To:* Eric Rescorla <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [TLS] Awkward Handshake: Possible mismatch of 
> client/server view on client authentication in post-handshake mode in 
> Revision 18
>
> Hi Ekr,
>
> As mentioned in my other email, one scenario we encountered this was 
> if (using your message numbering as reference) messages 5 or 9 
> happened to be a NewSessionTicket. In this case, the client might be 
> under the impression that they have a session ticket for a mutually 
> authenticated channel.
>
> Thanks,
>
> Sam
>
>         (rejecting a certificate but still continuing), and indeed
>         rejects the certificate, then the server should send an alert
>         message (or NAK of some form) for the property to hold in the
>         initial handshake.
>
>         scenario into account for the initial handshake, then it is
>         clear that this decision can only be made by the server in the
>         initial handshake, while in the post-handshake client auth, an
>         attacker can decide this (by dropping the message).
>
>         The reason we don't believe an explicit ACK is needed is
>         because upgrading to a new pair of keys explicitly provides
>         this. Specifically, the client will send all subsequent data
>         to the server under a new key. The server will not be able to
>         decrypt this data until they receive the client authentication
>         messages and upgrade the keys.
>
>         We agree that TLS enforcing ordering of messages provides
>         similar guarantees. However, we are analysing the
>         specification as it is presented, which does not guarantee this.
>
>         Thanks,
>
>         Sam
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 11 Feb 2017 11:20:01 -0800

> previously sending early data?

Yes, I think it will be, especially in cases where the server says the same
thing to every client (e.g., HTTP settings frames).
Probably a less often in cases where the initial handshake will demand
client auth.

> server wont send these before processing the client Finished,
>

Specifically: the EMS is derived from the client's entire transcript
through the client's Finished, so you can't compute it until then.

but it could still be an issue in the post-hs scenario.

Yes, NST is asynchronous wrt post-handshake auth, just like app data
messages.

-Ekr

> we've encountered. Hopefully it proves a useful insight into the guarantees
> (or lack thereof) provided  by client authentication. Also it is really
> useful in helping us to refine our model :)
>
> Sam
>
>
> *From:* TLS [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Sam Scott
> *To:* Eric Rescorla <[email-masked]> <[email-masked]>
> *Cc:* [email-masked]