On Thu, Feb 25, 2016 at 11:54 AM, Hugo Krawczyk <[email protected]> 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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
