On Thu, Feb 25, 2016 at 10:20 PM, Watson Ladd <[email protected]> wrote:
> 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. It is not pessimistic - it says that you either assume some form of client authentication verified by the server, implicitly or explicitly, or otherwise the server can only treat its 0.5 data as open to active attacks. > The below should be taken as a clever guess, rather than > representative of the truth. > You know that these intuitive argument *almost* always work. Problem is that all attacks are hiding behind the "almost" part ;-) I am not saying that something like this cannot be formalized, but it will not be easy, particularly since the ways of authentication are varied and depend on applications and semantics that are hard to reason about, let alone formalize mathematically. People can and will build on such assumptions but they should do that with a lot of care and with as much mathematical analysis behind it as possible. Hugo > > 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
