Subject: Re: [TLS] Triple Handshake Fix.

From: Bodo Moeller <[email-masked]>
Date: Mon, 5 May 2014 21:54:38 +0200

Nico Williams <[email-masked]>:
>
> > On Wed, Apr 30, 2014 at 2:15 PM, Bodo Moeller <[email-masked]> wrote
>

> >> [...] I think we'll need a requirement for clients and servers
> >> implementing this spec to do one of the following, because an attacker
> can't
> >> be expected to opt in to extended master secrets in its handshakes:
> >>
> >> (1) If the current session does not use an extended master secret, don't
> >> allow renegotiation.
> >>
> >> (2) If a session does not use an extended master secret, don't allow it
> to
> >> be resumed.
>
> Why not both?
>

As I wrote earlier, (2) is cleaner but would entirely prevent session
resumption between updated implementations and legacy implementations, and
thus doesn't seem viable to roll out immediately.  Losing session
resumption for most connections can be significant for computational cost
and latency.

Bodo

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 May 2014 15:01:51 -0500

On Mon, May 5, 2014 at 2:54 PM, Bodo Moeller <[email-masked]> wrote:
> thus doesn't seem viable to roll out immediately.  Losing session resumption
> for most connections can be significant for computational cost and latency.

(1) alone breaks tls-unique CB, so it's not acceptable unless there's
an API for extracting CB and that API makes tls-unique not available.
That might seem like a nit to some, but given the state of play in TLS
implementations' APIs I think any protocol fix (as opposed to new
features) that has API impact should be considered more carefully.
(Sure, it's not the end of the world.)

(2) is definitely cleaner and I don't see the interop problem: if an
old client connects to a new server then the server should not offer
resumption, while a new client connecting to an old server should not
use session resumption even if offered by the server.

(2) only results in reduced performance in old/new or new/old cases,
but those should disappear soon enough.

Nico
--

---

From: Martin Thomson <[email-masked]>
Date: Mon, 5 May 2014 13:20:34 -0700

On 5 May 2014 12:54, Bodo Moeller <[email-masked]> wrote:
> Losing session resumption for most connections can be significant for
> computational cost and latency.

At least those are the only costs.  At least the session can still be
established.  There are some use cases that depend on renegotiation
that cannot be addressed otherwise.  For instance, protecting client
certificates from passive inspection.

Neither option is good, but perhaps we can allow implementations (or
deployments) to pick what measure suits them (or both).  I'd certainly
put 2 down as the default.

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 5 May 2014 22:37:15 +0200

> certificates from passive inspection.

Yes, that's why I also wrote, "Maybe for servers you'd initially want to
pick either approach 1 or approach 2 depending on the particular needs
(whether renegotiation is needed at all), while clients initially could
allow *both* renegotiation and resumption for new sessions, where whichever
comes first for a given session would disallow the other."

> put 2 down as the default.

Things definitely should converge towards (2).

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 5 May 2014 22:44:32 +0200

> but those should disappear soon enough.

The point is, if you're the first to switch from "old" to "new", this would
affect *all* your connections.  (Indeed there's no interoperability problem
per se, but the performance hit can be nontrivial.)  Having (1) available
as an intermediate state would make it easier to switch early.

Bodo

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 May 2014 15:59:51 -0500

On Mon, May 5, 2014 at 3:44 PM, Bodo Moeller <[email-masked]> wrote:
> per se, but the performance hit can be nontrivial.)  Having (1) available as
> an intermediate state would make it easier to switch early.

Several optimizations are possible.  Here's a possible set of rules:

 - neither new clients nor new servers should permit renegotiation
within resumed connections when talking to an old peer

 - new clients should not permit resumption of renegotiated
connections to old servers unless the inner connection is bound to the
outer and

   - tls-unique will not be extracted or will be made unavailable when
talking to old servers

 - new servers should not offer nor permit resumption by old clients
when tls-unique CB may be extracted OR they should disallow tls-unique
CB extraction

Is that complete?  I think so.  But that's fairly complicated and
mistakes could be made in interpreting it.

We all need resumption fixed, and we're getting pretty good at
deploying new TLS implementations (because goto fail bug, because
heartbleed).  I'd rather simplify things by going with (2) alone.

Nico
--

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 5 May 2014 23:13:46 +0200

> heartbleed).

Well, these examples have fixes that you can just roll out fully on
whatever system you control without causing any disruption by doing so,
other than potentially to attackers: with these, there's no penalty for
moving first.  (2), unfortunately, isn't that easy.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 5 May 2014 14:59:11 -0700

On Mon, May 5, 2014 at 2:13 PM, Bodo Moeller <[email-masked]> wrote:
> Well, these examples have fixes that you can just roll out fully on whatever
> system you control without causing any disruption by doing so, other than
> potentially to attackers: with these, there's no penalty for moving first.
> (2), unfortunately, isn't that easy.

I vote for (1). Hardly anyone uses renegotation. Resumption is
commonly used on the web today. Let's hurt the uncommon usecase
instead of having a widespread performance regression.

Sincerely,
Watson Ladd
>
>
> _______________________________________________
> 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: Nico Williams <[email-masked]>
Date: Mon, 5 May 2014 18:03:16 -0500

> instead of having a widespread performance regression.

Even if we have consensus to remove renego in 1.3, for everyone else
there's a difference between "oops, it fails" and "hmm, it's not as
fast as usual".  This isn't hurting the uncommon use-case, but
breaking a rare but not that rare usage.

Nico
--

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 6 May 2014 11:49:08 +0200

> breaking a rare but not that rare usage.

I don't want to break renegotiation entirely, hence my suggestion to allow
servers to pick either (1) [disallow renegotiation with legacy clients] or
(2) [disallow session resumption for legacy clients] at first.

My concern regarding (2) is that "It's not as fast as usual" may actually
manifest as "My servers are suddenly overloaded and I'll have to revert the
software update".  (1) is meant for early adopters, so that they won't have
to regret being early adopters.  Past a certain stage of adoption, everyone
should just go to (2) directly.

Bodo