Subject: Re: [TLS] TLS process thread

From: Peter Gutmann <[email-masked]>
Date: Mon, 14 Apr 2014 03:31:11 +0000

Sean Turner <[email-masked]> writes:

>In this case, however, our charter provides a clear starting point, namely
>RFC 5246, and a mandate to minimize the changes to that document.

If the charter really does require that then it sounds like it's high time to
update the charter...

Peter.

---

From: Watson Ladd <[email-masked]>
Date: Sun, 13 Apr 2014 22:44:12 -0700

> If the charter really does require that then it sounds like it's high time to

In particular, we need to make significant changes to the handshake to
address insecure resumption, use a completely different record layer
because of Lucky13 (might as well make it AEAD, as Chacha20+Poly1305
and AES-GCM do that, and whatever fixed up AES+hash people want to use
can be shoehorned in), renegotiation is probably going to die as no
one needs it. (HTTP can use another header number to signal that you
need a certificate, a reconnection is not the worse thing in the
world, no one understands what renegotiation is supposed to do, and
client certificate sensitivity can be fixed by not putting real names
in them)

That's going to be a pretty big change from RFC 5246. Trying to keep
the textual changes minimal probably a lost cause at this point, and
will hurt, rather than help clarity. This is before we try to reduce
round-trips, eliminate unused ciphersuites, introduce the Edwards
curves (necessary for security because people do not write perfect
code, even when they should), and ensure that what we write matches
what we prove (because as I'm sure you know from my opposition to
Dragonfly, I do not support mechanisms that are not shown to be secure
from well picked assumptions)

We can't not make the first changes, and it seems like the second half
of the changes are going to happen anyway. Unless you want another
block of MTI extensions that obviate vast swaths of the RFC, the
entire protocol needs to be edited and presented as a whole. I don't
see a way to do that and adhere to "minimize changes".

Sincerely,
Watson Ladd

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

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 13 Apr 2014 23:24:17 -0700 (PDT)

> from well picked assumptions)

  Really? And Edwards curves will necessarily result in perfect code?
Certainly not as a result of draft-ladd-safecurves! So what assures
perfection in Edwards curves implementations then?

  Dan.

---

From: Brian Sniffen <[email-masked]>
Date: Mon, 14 Apr 2014 02:29:38 -0400

Watson Ladd <[email-masked]> writes:

> round-trips, ...

[...]

> I don't see a way to do that and adhere to "minimize changes".

The most complicating factor I can imagine is multiple regular protocol
roles, any of which could be run in parallel: three different ways a
client could behave and three different corresponding server behaviors.
They can even run in parallel, given an anycasted server!

The most important simplification I can imagine is to make the handshake
implementation crystal clear and dead simple, up through an
authenticated and encrypted channel: amenable to formal methods, to
automated search for differences from a verified implementation, and to
high-performance implementation without much risk.  I'd rather give up
fast session resumption for half a decade than continue with a fire-drill
of ~annual protocol vulnerabilities.

-Brian
"Implementation is hard" can be my motto for the week.

-- 
Brian Sniffen
Information Security
Akamai Technologies

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Apr 2014 06:56:12 -0700

On Sun, Apr 13, 2014 at 10:44 PM, Watson Ladd <[email-masked]> wrote:

> address insecure resumption,use a completely different record layer

> can be shoehorned in),

The latter already exists in Section 6.2.3.3 of RFC 5246.

http://tools.ietf.org/html/rfc5246#section-6.2.3.3

All that's required is removing 6.2.3.1 and 6.2.3.2 which define block
and stream ciphers and merging any of the relevant text from those
into the AEAD section.

> renegotiation is probably going to die as no

Also a simple matter of removing text, though I don't think it's clear
that we will actually be able to get away with this.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Apr 2014 07:14:09 -0700

On Sun, Apr 13, 2014 at 11:29 PM, Brian Sniffen <[email-masked]> wrote:
> high-performance implementation without much risk.

This certainly seems like a useful goal, but  of course likely
requires feature set tradeoffs. As I noted in London, probably the
biggest complicating feature is SNI encryption, so I'd like to take
this opportunity to ask people to read and respond to Rich Salz's
message about that:

http://www.ietf.org/mail-archive/web/tls/current/msg11823.html

Which reminds me that I need to do so myself....

-Ekr