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 < karthik.bharga...@gmail.com> 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 <martin.thom...@gmail.com> >> 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 >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
