Subject: [TLS] TRON workshop

From: Stephen Farrell <[email-masked]>
Date: Thu, 8 Oct 2015 22:20:42 +0100

Hiya,

First, thanks all for all your ongoing work on TLS1.3. I'm sure we're
all aware that this is important stuff that needs to be, and is being,
done carefully with due attention to security analysis.

Early in the process we had some brief discussion of pausing towards
the end of the work to give folks a chance to do analyses of the
security and other properties of TLS1.3 just before publication of
the RFC.

Chatting with the chairs in Prague and with various others since, we
think we've reached the point where we need to start executing that bit
of the plan, since doing such analyses also takes time and we don't
want to add a big delay if we can avoid it. So we're organising a
workshop on just that topic to be co-located with NDSS in San Diego
in late February 2016.

The call for papers is at [1], please read that and circulate to folks
who you think could produce useful analyses that can help the WG get
an even higher quality TLS1.3 out the door.

I'm sure some of you will be wondering about invites to this workshop
etc. We'll have to see how many submissions we get and the level of
interest and figure out logistics etc closer to time, but this clearly
does need a bunch of folks in the room who are important contributors
to the WG but who won't be submitting papers. I'll work with the
workshop programme committee and the WG chairs to figure out how best
to handle that, via invites, remote access if possible etc. More on
that as we figure it out. (Feel free to send me and/or the WG chairs
your thoughts and offers for help on that.)

And just to clarify a possible process question - this workshop will
provide input - we're hoping that'll be very high quality input but
the normal WG consensus process will be used to process that input in
all the usual ways. Think of TRON as being a mega-big design team on
steroids if that helps. (Lousy imagery, I know:-) If the workshop
indicates that TLS1.3 is fine then that's fairly obviously great, if
there are significant new issues identified though, those will need
to be brought to this list, and to meetings at IETF95, for resolution
via our normal process.

Cheers,
S.

[1]
https://www.internetsociety.org/events/ndss-symposium-2016/tron-workshop-call-papers

---

From: Hubert Kario <[email-masked]>
Date: Mon, 12 Oct 2015 13:40:26 +0200

On Thursday 08 October 2015 22:20:42 Stephen Farrell wrote:
> think we've reached the point where we need to start executing that
> bit of the plan, since doing such analyses also takes time and we
> don't want to add a big delay if we can avoid it. So we're organising
> a workshop on just that topic to be co-located with NDSS in San Diego
> in late February 2016.

aren't we still missing the 0-RTT mode?
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Oct 2015 04:48:08 -0700

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

-Ekr

-
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 12 Oct 2015 17:58:03 +0300

On Mon, Oct 12, 2015 at 04:48:08AM -0700, Eric Rescorla wrote:
> 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.

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)?

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.

If such authentication is not needed, 1-RTT authentication would be
equally fast as 0-RTT authentication (now that 1-RTT auth does not
prohibit server 0-RTT) and much more straightforward (due to having
full-fledged connection context).

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?

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Oct 2015 08:04:37 -0700

> is right now isn't really sufficient to analyze it.

Yes, that's the plan, as noted above.

> was about this (I can't get more usual types of attacks to work)?

Yes, that's the idea.

> 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

> 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

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 12 Oct 2015 19:05:39 +0300

> > was about this (I can't get more usual types of attacks to work)?
 
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).
 
> know how much this alters the analysis. And yes, we do have settings

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?

> I'm assuming that in these cases the server has global state and so doesn't

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