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 Fri, Feb 10, 2017 at 12:52 PM, Sam Scott <[e-mail]> wrote:

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

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).


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

Yes, I agree with this.

-Ekr


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