Re: [TLS] TRON workshop

[Eric Rescorla <[e-mail]>]

On Mon, Oct 12, 2015 at 7:58 AM, Ilari Liusvaara <[e-mail]>
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 <[e-mail]> 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
>