On 4/2/16, 14:53, "Karthik Bhargavan" <karthikeyan.bharga...@inria.fr> wrote:
> >Here is a proposal that would avoid trial decryption. >When the client sends 0-RTT application data, it currently >ends this flight of messages with an encrypted end_of_early data warning alert. >How about: if the server rejects trial decryption, the client >must then send an *unencrypted* end_of_early_data warning alert before >continuing with 1-RTT handshake data. >The server could then easily discard all records until it sees this warning >alert. > >The main disadvantage of this approach seems to be that it reveals to the >adversary >the point at which the 0-RTT application data ends (if this is sensitive >information.) >However, note that if the length of 0-RTT data was sensitive, an attacker >could probably already obtain it by delaying the server flight. > >Does anyone see other practical or security disadvantages to using this alert? I tried to think of ways that a misbehaving client (or attacker) could cause a server relying on the unencrypted alert to consume resources and sit around waiting for a long time, but it seems like the unencrypted alert is strictly better than trial decryption in that regard (since the server doesn't have to burn CPU on decryption). So, it seems that revealing the length of the 0-RTT data is the main disadvantage, but as Ilari notes, there are likely to be other channels that would leak that boundary in many cases. Using the unencrypted alert does also provide a clear indication that the client/server failed to exchange 0-RTT data; for a PSK mode with a cache of 0-RTT sessions this could provide a window into the validity periods used by the two parties or as a signal that a finite-sized cache is full and ejecting old entries. Perhaps an attacker could use that signal to determine the rate of some other sort of attack that requires getting a session evicted from the cache, but the need for such a signal seems pretty hypothetical, given that an attacker can already claim to be as many different clients as it wants. -Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
