On Mon, Oct 12, 2015 at 7:58 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Mon, Oct 12, 2015 at 04:48:08AM -0700, Eric Rescorla wrote: > > On Mon, Oct 12, 2015 at 4:40 AM, Hubert Kario <hka...@redhat.com> wrote: > > > > > aren't we still missing the 0-RTT mode? > > > > It's in the current draft though there are a few details that we're > > going to need to nail down over the next few weeks and in Yokohama. > > IMO, that should be nailed rather quick, given that that what there > is right now isn't really sufficient to analyze it. > Yes, that's the plan, as noted above. > However, some comments about 0-RTT: > > > 1) It seems to me that if server key is compromised, MITM can > substitute 0-RTT data with its own (at least if original and modified > one have the same number of records). And such modification will not > be detected by handshake, which will complete successfully. > > Perhaps the comment about impersonation with compromised server key > was about this (I can't get more usual types of attacks to work)? > Yes, that's the idea. 2) If static client authentication is used with 0-RTT data, the client > authentication always preceeds 0-RTT data (it is first in early > handshake, and using 1-RTT client auth is forbidden). This seems to > imply 0-RTT data should be interpretted in an authenticated context, > which seems dangerous given the replayability of the 0-RTT data. > Well remember that applications already have this problem because they send cookies and the like in their HTTP requests. So, I don't know how much this alters the analysis. And yes, we do have settings where we need this 3) The document talks about making 0-RTT data unreplayable by using > extra identifier agreed out-of-band. Does that actually work, given > the likely auto-replay by the client? I'm assuming that in these cases the server has global state and so doesn't have a problem. -Ekr > > > -Ilari >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
