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

[Eric Rescorla <[e-mail]>]

On Sat, Feb 11, 2017 at 6:52 AM, Sam Scott <[e-mail]> wrote:

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

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.


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

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


> 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:
>
> 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:[e-mail] <[e-mail]>] *On
> Behalf Of *Sam Scott
> *Sent:* Friday, February 10, 2017 12:53 PM
> *To:* Eric Rescorla <[e-mail]> <[e-mail]>
> *Cc:* [e-mail]
> *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
>
> On 10/02/17 20:39, Eric Rescorla wrote:
>
> 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
>
>
>
>
>
>
>