Subject: [TLS] tls 1.3: renegotiation

From: Sean Turner <[email-masked]>
Date: Mon, 21 Jul 2014 11:21:47 -0400

At the TLS interim meeting held on Sunday July 20th, 2014, there was consensus to remove renegotiation on the assumption we will provide a rekeying facility of some form and client initated client authentication.  This message serves to confirm that consensus.  Please indicate by July 25th, 2014 whether you disagree with this (and why).

spt

---

From: Robert Ransom <[email-masked]>
Date: Fri, 25 Jul 2014 12:27:40 -0700

On 7/21/14, Sean Turner <[email-masked]> wrote:
> At the TLS interim meeting held on Sunday July 20th, 2014, there was
> consensus to remove renegotiation on the assumption we will provide a
> rekeying facility of some form and client initated client authentication.
> This message serves to confirm that consensus.  Please indicate by July
> 25th, 2014 whether you disagree with this (and why).

I oppose removal of renegotiation, for the following reasons:

* Renegotiation is a single feature which serves many purposes.  I
  believe that fixing the design, APIs, and implementations of
  renegotiation will be easier than designing the protocols, designing
  the APIs, and implementing every feature which would be needed to
  replace it.

* The client-initiated client authentication feature will require a
  ‘channel binding’ to the existing TLS connection, which -- as Nico
  Williams has pointed out -- is sufficient to work around
  renegotiation-based attacks at the protocol level, by binding the
  application data sent before renegotiation to the authentication
  performed during the renegotiation handshake.  Adding a channel
  binding to renegotiation would not require as many changes to
  existing code as adding an entirely new client authentication
  feature would, and would provide less room for new implementation
  bugs to creep in.

* Renegotiation can share most of its code with the implementation of
  the initial connection handshake, even after a channel binding is
  added to it.  Each of the new features added in order to replace
  renegotiation is likely to share considerably less code with the
  initial handshake, and their implementations are likely to receive
  considerably less use and less testing than any piece of code used
  in implementing renegotiation.

In addition, I believe that it is not possible for the WG to make an
informed decision as to whether renegotiation should be removed at
this time:

* The rekeying feature and client-initiated client authentication
  feature have not been specified yet, even to the point of stating
  the requirements which each feature will meet.  It is not possible
  for the WG to determine whether the features intended to replace
  these two uses of renegotiation will be fit for their intended
  purposes at this time.

Robert Ransom

---

From: Andrei Popov <[email-masked]>
Date: Mon, 28 Jul 2014 20:11:32 +0000

I agree with Robert, and oppose removal of renegotiation for the reasons listed. 

Also, the removal of renegotiation will complicate the deployment of TLS1.3 and limit its applicability. E.g. it is not clear to me how these configurations would work (when TLS client auth is required):
1. TLS 1.3 with an existing HTTP/1.1 server;
2. Existing TLS 1.2 library with HTTP/2 stack on top of it.

It looks like one would need to deploy  both TLS1.3 and HTTP/2 at the same time. Once TLS 1.3 and HTTP/2 are deployed, the way a site implements TLS client auth will depend on the combination of TLS version and HTTP version negotiated:
TLS1.3 + HTTP/2 -> New-style TLS client auth (TBD).
TLS1.3 + HTTP/1.1 -> No way to support TLS client auth?
TLS1.2 + HTTP/2 -> No way to support TLS client auth?
TLS1.2 + HTTP/1.1 -> TLS client auth via renegotiation.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Robert Ransom
Sent: Friday, July 25, 2014 12:28 PM
To: Sean Turner
Cc: [email-masked] ([email-masked])
Subject: Re: [TLS] tls 1.3: renegotiation

On 7/21/14, Sean Turner <[email-masked]> wrote:
> This message serves to confirm that consensus.  Please indicate by 
> July 25th, 2014 whether you disagree with this (and why).

In addition, I believe that it is not possible for the WG to make an informed decision as to whether renegotiation should be removed at this time:

Robert Ransom

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 28 Jul 2014 14:02:03 -0700

> TLS1.2 + HTTP/1.1 -> TLS client auth via renegotiation.

Client authentication is still possible, it just has to come in the
opening handshake.  Your concern is spontaneous client authentication.

HTTP/2 forbids renegotiation entirely, but permits it before HTTP/2
starts (to allow for client certificate confidentiality, if that is
desired).

That means that for HTTP/2 at least, the need isn't there.  They are
already looking for alternatives.

And it's not that alternatives don't exist, it's more the case that we
disagree on the viability aspects, I think.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 28 Jul 2014 14:17:46 -0700

>   these two uses of renegotiation will be fit for their intended

We had a good discussion about these in Toronto.  On rekeying, there
are concerns about how much we might want to make changeable; offline
discussions about the complexity/value trade-off space between simple
rekeying (as I have proposed) and something more complete like a full
DH exchange was quite enlightening.

We've talked quite a bit about spontaneous client authentication
(though we might talk about client-initiated authentication, that
implies a solution and so I think that is the wrong focus for the
discussion).

The problem as always is that the defense of renegotiation is largely
based on its existence alone.  That defense would be stronger if there
it were based on use cases.  I don't find arguments from inertia ("it
exists", or "it's easy") to be at all persuasive.  Saying "it can be
fixed" is actively detrimental to the case.

Arguments in the form "I need to do X and in order to do X I need
renegotiation" are far better.  They are testable.  Andrei's concerns
are a good example of this.  We might disagree on the subjective
elements, but that's a good starting point.

---

From: Robert Ransom <[email-masked]>
Date: Mon, 28 Jul 2014 15:03:36 -0700

> DH exchange was quite enlightening.

I see.  So you don't even have a consensus on what “rekeying” will mean.

> elements, but that's a good starting point.

I gave a list of four use cases that can be (and are currently)
addressed by renegotiation a while back.  The responses can be summed
up as “But we can add a separate ad-hoc feature to address each of
those use cases!”.  I agree that each use of renegotiation can be
replaced with a new protocol feature, which will require new protocol
design effort, new implementation code, new testing, new API design
effort, new application code, and new risk of introducing security
bugs at each of those steps.  I do not agree with your argument that
such a replacement is desirable for every use of renegotiation -- or
for *any* use of renegotiation at all.

Renegotiation is a particularly elegant solution to several problems.
It requires little extra code beyond what is already used to perform
the initial handshake, and adding a (correctly designed) channel
binding as input to the renegotiation process will add the security
properties that some API and application developers had previously
expected renegotiation to provide.

I don't find arguments based on the prospect that new features might
be added to TLS to be at all persuasive.  Saying
“TLS-without-renegotiation can be fixed to support long-lived
connections if we decide to add some sort of rekeying mechanism.” or
“We added a Heartbeat record type; now let's add a ClientAuthenticate
record type too!” are actively detrimental to the case.

Robert Ransom

---

From: Andrei Popov <[email-masked]>
Date: Mon, 28 Jul 2014 22:24:09 +0000

> Client authentication is still possible, it just has to come in the opening handshake.  Your concern is spontaneous client authentication.
Correct, I am concerned because a lot of sites choose to serve landing pages without client auth, and then request client auth with an appropriate cert once the user navigates to a particular protected resource. This scenario works today, but seems to be hard (or impossible?) to implement when TLS1.3 and HTTP/2 are negotiated.

> HTTP/2 forbids renegotiation entirely, but permits it before HTTP/2 starts (to allow for client certificate confidentiality, if that is desired).

> That means that for HTTP/2 at least, the need isn't there.  They are already looking for alternatives.
Are you saying that because HTTP/2 designers chose to ban renegotiation, the customers no longer need to perform TLS client auth in the middle of a connection? Perhaps I'm missing this point.

> And it's not that alternatives don't exist, it's more the case that we disagree on the viability aspects, I think.
The alternatives would need to address all the combinations of TLS and HTTP versions (and I believe the alternatives proposed so far don't). Also, there should be some way to encapsulate the alternatives such that sites don't need to fork client auth code for different TLS + HTTP version combinations. Next, it is not desirable to add latency compared with the existing solution. And if we can get this to work for all application protocols (not just HTTP), even better. Hopefully the result will prove to be worth the design and implementation effort:).

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, July 28, 2014 2:02 PM
To: Andrei Popov
Cc: Robert Ransom; Sean Turner; [email-masked] ([email-masked])
Subject: Re: [TLS] tls 1.3: renegotiation

> TLS1.2 + HTTP/1.1 -> TLS client auth via renegotiation.

Client authentication is still possible, it just has to come in the opening handshake.  Your concern is spontaneous client authentication.

HTTP/2 forbids renegotiation entirely, but permits it before HTTP/2 starts (to allow for client certificate confidentiality, if that is desired).

That means that for HTTP/2 at least, the need isn't there.  They are already looking for alternatives.

And it's not that alternatives don't exist, it's more the case that we disagree on the viability aspects, I think.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 28 Jul 2014 16:05:44 -0700

On 28 July 2014 15:24, Andrei Popov <[email-masked]> wrote:
> The alternatives would need to address all the combinations of TLS and HTTP versions (and I believe the alternatives proposed so far don't). Also, there should be some way to encapsulate the alternatives such that sites don't need to fork client auth code for different TLS + HTTP version combinations.

That's fairly straightfoward.  My strawman proposal is
protocol-version-agnostic.

> Next, it is not desirable to add latency compared with the existing solution. And if we can get this to work for all application protocols (not just HTTP), even better. Hopefully the result will prove to be worth the design and implementation effort:).

I'm less sensitive to latency in these cases.  With a 0-RTT handshake,
it could be that HTTP/2 on a new connection would be faster than what
currently occurs, since from the point of HelloRequest, the server
needs to wait for two RTT from the client before it can send data.
(If the request contains a body that doesn't fit into the first flight
congestion window, then I might concede that it is slower.)

---

From: Martin Thomson <[email-masked]>
Date: Mon, 28 Jul 2014 16:20:14 -0700

On 28 July 2014 15:03, Robert Ransom <[email-masked]> wrote:
> So you don't even have a consensus on what “rekeying” will mean.

That's step 2.  Do you think that this has a material impact on the
outcome of this call?  (I'm guessing not.)

> addressed by renegotiation a while back.

I can't find these.

> expected renegotiation to provide.

It might be conceptually elegant, but it's certainly not free.  Even
within NSS, the number of "if we are renegotiating" branches is pretty
large.

And fixing NSS is relatively easy.  It's the externalities
renegotiation creates that are the larger problem.  Because API and
application developers don't look for particular properties, the
problem is with the assumptions, once of which is generally
immutability of various properties.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 29 Jul 2014 09:27:38 +0200

> immutability of various properties.

Then please fix the provided by NSS API to make these assumptions
explicit to the applications rather than arguing to change the protocol
for everyone. 

regards,
Nikos