Subject: [TLS] Renegotiation: trying to summarize

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Jun 2014 15:44:08 -0700

It's been a long thread, I think a recap is in order.  Here's the
options I've seen thus far:

1. Remove renegotiation entirely

Brian Smith proposed this.  Arguments for are its beautiful simplicity
and the fact that it ensures that you limit the time that a single
session (and the corresponding keys) live.  Arguments against are that
it doesn't allow for long-lived connections; and we've evidence
(thanks David) that suggests that rekeying on very short timescales is
interesting to some TLS users, misguided or not.

2. Remove renegotiation and replace it with a key refresh

This is what I've proposed, though the details could easily be
different (e.g., you could do a new DH exchange for maximal PFS, or
you could invent a new message type).  The advantage over #1 is that
you can have a much longer connection lifetime.  That could equally be
considered a disadvantage.

3. End TLS and use the same L4 for a new session

Here we effectively end TLS, but keep the TCP connection (or
equivalent) around for use in a new TLS session.  In some versions,
this has an "end TLS" message that signals the end of the old session.
In others, starting a new handshake terminates the old session
implicitly.

Some have suggested that it be phrased in API terms as a new
connection, that the application needs to request a new connection to
get the handshake to happen.  In others, this is just a different spin
on renegotiation, with a little dead air while everything is changed
out.  In the latter case, I don't see how this is any different to
retaining renegotiation.  The former seems like an optimization of #1.

4. It ain't broke, don't fix it

The general thread here is that any problems are either fictional, or
the result of problems in the TLS API or the application that uses it.

In short, I think that #1 and #2 suggest that there is a potential
problem if session properties can change; #3 and #4 reject that
thesis.

You could treat the 1&2 vs. 3&4 as the high order bit.  Then, you
either choose to limit the lifetime of sessions (#1) or go long (#2).
Alternatively, you decide whether to break sessions apart (#3) or keep
the old renegotiation scheme (#4).  On the other hand, 3 could looks a
lot like an optimization of #1, though it might suggest the potential
to get things wrong.

---

From: Andrei Popov <[email-masked]>
Date: Thu, 19 Jun 2014 23:19:30 +0000

This is a good summary, thanks Martin. It also seems that #1 and #2 break (or significantly complicate) existing TLS client auth scenarios, while #3 and #4 allow these client auth scenarios.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Thursday, June 19, 2014 3:44 PM
To: [email-masked]
Subject: [TLS] Renegotiation: trying to summarize

It's been a long thread, I think a recap is in order.  Here's the options I've seen thus far:

Brian Smith proposed this.  Arguments for are its beautiful simplicity and the fact that it ensures that you limit the time that a single session (and the corresponding keys) live.  Arguments against are that it doesn't allow for long-lived connections; and we've evidence (thanks David) that suggests that rekeying on very short timescales is interesting to some TLS users, misguided or not.

This is what I've proposed, though the details could easily be different (e.g., you could do a new DH exchange for maximal PFS, or you could invent a new message type).  The advantage over #1 is that you can have a much longer connection lifetime.  That could equally be considered a disadvantage.

Here we effectively end TLS, but keep the TCP connection (or
equivalent) around for use in a new TLS session.  In some versions, this has an "end TLS" message that signals the end of the old session.
In others, starting a new handshake terminates the old session implicitly.

Some have suggested that it be phrased in API terms as a new connection, that the application needs to request a new connection to get the handshake to happen.  In others, this is just a different spin on renegotiation, with a little dead air while everything is changed out.  In the latter case, I don't see how this is any different to retaining renegotiation.  The former seems like an optimization of #1.

The general thread here is that any problems are either fictional, or the result of problems in the TLS API or the application that uses it.

In short, I think that #1 and #2 suggest that there is a potential problem if session properties can change; #3 and #4 reject that thesis.

You could treat the 1&2 vs. 3&4 as the high order bit.  Then, you either choose to limit the lifetime of sessions (#1) or go long (#2).
Alternatively, you decide whether to break sessions apart (#3) or keep the old renegotiation scheme (#4).  On the other hand, 3 could looks a lot like an optimization of #1, though it might suggest the potential to get things wrong.

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Jun 2014 16:23:19 -0700

On 19 June 2014 16:19, Andrei Popov <[email-masked]> wrote:
> It also seems that #1 and #2 break (or significantly complicate) existing TLS client auth scenarios, while #3 and #4 allow these client auth scenarios.

Indeed.  This is perhaps the biggest drawback to making session
properties immutable.  We know that people use this feature.

Personally, I think that we can find a better solution for that.  I've
proposed one option that relies on changes in the application
protocol; others have suggested that we could provide a facility
within TLS to support this use case.  Depending on what you think of
those options, it might reduce the severity of losing the feature.

---

From: Geoffrey Keating <[email-masked]>
Date: 19 Jun 2014 16:43:24 -0700

Andrei Popov <[email-masked]> writes:

> This is a good summary, thanks Martin. It also seems that #1 and #2
> break (or significantly complicate) existing TLS client auth
> scenarios, while #3 and #4 allow these client auth scenarios.

I believe there was also a proposal to allow client auth at any point
during the session, but not renegotiate: no new ciphers, no new keys,
just send CertificateRequest and get back Client Certificate and
CertificateVerify.  This does prevent use of client certificates with
encryption-only algorithms, but it seems such a thing should be used
from the start of the connection anyway.

Compared to renegotiation this allows many simplifications:
- It can't affect the confidentiality of the session
- The server's identity cannot change
- The authentication is of the whole handshake from the start, so
  there's no possibility of some earlier unauthenticated state
  affecting the rest of the session
- You can request multiple authentications and all of them apply to
  the entire session so far including previous authentications
  (a property that current TLS is vague about)
- No random numbers are needed (at least for RSA certificates)

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 19 Jun 2014 22:25:23 -0400

> In short, I think that #1 and #2 suggest that there is a potential problem if session properties can change; #3 and #4 reject that thesis.

I don't see how #3 "rejects that thesis."  Actually, looking at your note I would disagree with all of your characterization.  To me, #3 says that change is a problem, so explicitly start a new session if you want to change things.
 
> Some have suggested that it be phrased in API terms as a new connection, that the application needs to request a new connection to get the handshake to happen.  In others, this is just a different…

I was thinking that since the TCP(whatever) connecdtion was open, both client and server would already "know" who was on the other side, and if the restarted connection ended up with different identities (on either side), it could signal an error to the application.  Or, either side MAY send an alert if the identity is "unexpected" or different. Maybe that's a SHOULD or even a MUST. Also, for I'd expect that the client could now use the 0RT since it has the server's DH key.

	/r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]; Twitter: RichSalz

---

From: Martin Thomson <[email-masked]>
Date: Fri, 20 Jun 2014 09:21:38 -0700

> I was thinking that since the TCP(whatever) connecdtion was open, both client and server would already "know" who was on the other side, and if the restarted connection ended up with different iden…

That's detail that wasn't clear.  So the idea is that only some
properties would be effectively immutable, and that immutability is
enforced by the stack.  Identity seems like an obvious candidate for
immutability, but that would prevent the spontaneous client
authentication use case.  We'd need careful rules around what can
change, what requires an alert, and what causes the connection to
abort.

I'll note that 0RTT could reduce the amount of dead air, but not
entirely eliminate it.  Server initiated restarts (as opposed to
renegotiation) would lose time if they had to stop sending at that
point.  And for clients, we currently have a limitation with the 0RTT
handshake in that the first flight of data needs to be entirely
contained in the encrypted ClientHello extension.  You can't trickle
data out without risking an explosion from non-1.3 servers.
Obviously, you know that the server talks 1.3, so maybe we can have
different logic here to allow for regular data to flow...  You see
where I'm going?

---

From: [email-masked] (Martin Rex)
Date: Wed, 25 Jun 2014 01:43:51 +0200 (CEST)

> Compared to renegotiation this allows many simplifications:

I believe that just the opposite is true, this opens a whole new can
of worms.

Really, the existing renegotiation is both strong and simple.

For most of our (customer's) usage scenarios, TLS session caching
is a MUST, and the session caching concept with renegotiation is
simple and clear.

A TLS session that authenticates only the server (certificate) within
TLS has different properties than a TLS session that authenticates
both, client&server.   With traditional renegotiation, these are
distinct SSL sessions (as far as caching is concerned), and either
one can be resumed.

The most common use of renegotiation is to change the status of
one (or both) peers from not authenticated in the existing session
to authenticated in the renegotiated session.

There was a problem with TLS implementations *NOT* nailing down
an authenticated identiy to _not_change_ during renegotiation, unless
the application has specifically requested for this to be allowed
through new/non-standard API calls (this is nothing that should happen
to an application by mere configuration tweaks).  This problem has
already been described in the security considerations of rfc5746
and it was the interim workaround suggested to browsers for the
triple-handshake-attack (which seem to have boldly ignored the
issue from the rfc5746 security considerations section...).

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Tue, 24 Jun 2014 19:18:28 -0700

> distinct SSL sessions (as far as caching is concerned), and either

Yes, this is a problem that has to be carefully considered if we
permit state changes in TLS.

> issue from the rfc5746 security considerations section...).

There is nothing a client can do about the original renegotiation
issue. With Triple-Handshake some usages (tls-unique channel bindings)
are doomed, and others (web authentication) have to take special care
that server names don't change on renegotiation, even though it was
"fixed".

It's not surprising that people ignored the need for client-side
fixes, because rfc5746 had an extension that claimed to fix the
problem without rewriting code.

However, end of the day we have to deal with the implementations and
code that we have. 90% of it cannot handle renegotiation correctly in
the most general form. So we need to restrict the semantics, and how
we do that I don't know, because I don't know what the expected
semantics are.

Sincerely,
Watson Ladd

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

---

From: Geoff Keating <[email-masked]>
Date: Tue, 24 Jun 2014 21:51:23 -0700

> is a MUST, and the session caching concept with renegotiation is

I think there is strong evidence to the contrary: If it was simple and clear, the triple handshake attacks would not have been possible.

> distinct SSL sessions (as far as caching is concerned), and either

So, in current TLS, if a session is established with no client authentication, and then there's renegotiation with a client certificate, and then the first session is resumed, has that resumed session been authenticated by the client certificate?  It seems like with the renegotiation fix, the entity that established the second session has signed data that associates them with the first session.  Did they mean to do that?  Will the server interpret it that way?  Is it safe for the server to interpret it that way?

> to authenticated in the renegotiated session.

Actually, it is used to change the status in *both* sessions.  In HTTPS, the protocol exchange does not go:

-> PUT authenticated path
<- please renegotiate, and now I want a client auth
<> renegotiation
<- thank you, but your previous request gets an error because it was sent before you authenticated
-> PUT authenticated path
<- OK, send me the data

what actually happens is:

-> PUT authenticated path
<- please renegotiate, and now I want a client auth
<> renegotiation
<- thank you, send me the data

The server uses the renegotiation to authenticate the request sent before the renegotiation.  (I used PUT here to make it clearer, but the same principle applies to a regular GET request.)