Re: [TLS] TRON workshop

[Ilari Liusvaara <[e-mail]>]

On Mon, Oct 12, 2015 at 08:04:37AM -0700, Eric Rescorla wrote:
> On Mon, Oct 12, 2015 at 7:58 AM, Ilari Liusvaara <[e-mail]>
> wrote:
> >
> > 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.
 
If so, I think the note is really unclear. Maybe something like:

"If the server key is compromised, then the attacker can tamper with
the 0-RTT data without detection.".

(The reason I can't make straightforward impersonation to work is that
the signature presumably signs unknown client DH keys and server sends
fresh DH keys, so one can't compute the ES and contine past when
connection goes encrypted).
 
> 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

At least HTTP has safe methods (GET) and also HTTP/2 has prelude (which
is connection-scoped) one might want to send as 0-RTT data.

And also, can you give some examples of settings where authenticating
0-RTT data is needed?

 
> 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.

I was thinking of stuff like this:

1) Client sends 1st flight to server, gets intercepted by attacker.
2) Attacker sends the 1st flight to server twice.
3) Attacker resets the connection where server accepts the data.
4) Attacker starts forwarding other data.
5) Client sees 0-RTT failed. Completes handshake.
6) Client compensates for failed 0-RTT and essentially causes a replay.

(Which I think actually did come up when DKG broke the heck out of
0-RTT anti-replay).


And while at it, although this isn't about 0-RTT:

4) Currently the handshake "restart" anti-tampering works by
continuing the hashes. This has nice security properties seemingly
difficult to replicate in other settings.

I have identified three kinds of attacks against handshake "restart":
- Attacker tampering with first ClientHello.
- Attacker tampering with returned HelloRetryRequest.
- Attacker causing handshake restart on serverside without client
  knowing.

Current "continue the hashes" prevents all those attacks by causing
handshake to unavoidably fail. 

It seems to me that other approaches rely on client and server
performing checks, and given the complexity of things like checking
ClientHello, I give chance of epsilon squared (= very^2 small) that
there isn't going to be implementations that get that badly wrong.



-Ilari