Re: [TLS] 0.5 RTT

[Watson Ladd <[e-mail]>]

On Thu, Feb 25, 2016 at 11:54 AM, Hugo Krawczyk <[e-mail]> wrote:
> As I said in another email, without client authentication (which is the
> scenario in the Karthik quote), data sent by the server should be considered
> secure only against passive adversaries. Any additional assumption on
> confidentiality (i.e., restricting the power of an active attacker) must
> consider some form of client authentication, either implicit or explicit.
> Both cases must be dealt with with care, especially the implicit ones (e.g.
> authentication implied by application mechanisms and semantics).

I think this is unnecessarily pessimistic/ignores the ways in which
higher-level applications may have authentication and what we need
from them. The below should be taken as a clever guess, rather than
representative of the truth.

First, we know that negotiation doesn't work in 0-RTT. But that's ok:
we need to limit to only strong ciphers anyway, because negotiation
doesn't work/general depreciation. This means that clients can be
fooled by attackers into using the weakest notion they support for
continued authentication of PSKs: this applies to resumption with
tickets as well.

We also know that each PSK is only shared between one server and one
other client from the unpredictability of the negotiated keys. And so
when when a server decrypts a ticket, it knows that whatever data it
saved in the ticket negotiated in the original negotiation applies to
whoever sent it this 0-RTT data, and it knows its response will go
only to someone who *at one point* sent this 0-RTT data. And so if
there is a cookie or url parameter authenticating the client that is
not tied to the PSK, so long as the PSK is secure there is only one
party that could have sent that cookie, and the response will go to
it. The same is true for prior client authentication, saved in the
ticket.

Formalizing the above is likely to be a bit tricky, but I don't see
why it wouldn't be possible.

>
>
> On Thu, Feb 25, 2016 at 7:29 AM, Martin Rex <[e-mail]> wrote:
>>
>> Karthikeyan Bhargavan wrote:
>> >
>> > Yes Hugo, you?re right that when there is no client auth,
>> > the situation is less problematic.
>>
>> I'm not so sure.
>>
>> There might be the desire of the server to keep some data confidential,
>> and your argument is that if the data wasn't confidential to begin with,
>> the server is not "breaking" confidentiality--although the server is
>> clearly doing this.
>>
>> But what about the client and the client's desire to keep confidential,
>> which particular "public data" it is just requesting and receiving
>> from the server.
>>
>>
>> -Martin
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.