Re: [TLS] 0.5 RTT

[Watson Ladd <[e-mail]>]

On Feb 23, 2016 2:27 PM, "Hugo Krawczyk" <[e-mail]> wrote:
>
> 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.

Authentication is also handled at a higher layer through HTTP cookies or
token binding. We need to ensure our analysis covers these interactions.

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

I think we should seperate a conservative TLS 1.3 core consisting only of
those features we are absolutely certain function together well, with RSA
endpoint cert signatures banned, and no 0-RTT, and encourage implementors
to make it easy to restrict to this subset.

>From TRON my impressesion is that this includes 1-RTT exchanges and so is
already a latency gain over existing TLS.

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