Re: [TLS] 0.5 RTT

[Hugo Krawczyk <[e-mail]>]

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 <
[e-mail]> 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.
>
>
> 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
>
>
>
> 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
>>        not being the same as 1-RTT keys. Again, so far, this is a matter
>> of taste and proof modularity.
>>
>
>
> ​Agreed.
>
> Hugo
>
> ​
>
>
>> > On 23 Feb 2016, at 11:27, Martin Thomson <[e-mail]>
>> wrote:
>> >
>> > 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.
>> >
>> > _______________________________________________
>> > TLS mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>