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

[Eric Rescorla <[e-mail]>]

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 <[e-mail]> 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).
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>