Subject: Re: [TLS] Proposed text for removing renegotiation

From: [email-masked] (Martin Rex)
Date: Sat, 7 Jun 2014 00:30:45 +0200 (CEST)

Brian Smith wrote:
> Martin Rex <[email-masked]> wrote:
>>
>> Conceptually, the TLS session cache is readonly after an entry
>> is created, and that is GOOD, i.e. full TLS handshakes create new,
>> distict session cache entries, and abbreviated TLS handshakes resume
>> existing session cache entries and *NEVER* modify them.
> 
> That is not true. During session resumption, the server can send a new
> session ticket for the existing session and the client has the option of
> adding the new ticket to the session (and removing the old ticket).
> 
> Also often timestamps (e.g. for LRU replacement bookkeeping) and/or
> counters (e.g. for cache hit rate statistics) in a session are updated
> during resumption, though these are "just" implementation issues.

With "conceptually", I referred to the requirements of the specification,
not to the details of certain implementations of it.  Counting how often
sessions are resumed is nothing that the spec requires, and how you
manage your cache entries (expiration) is not in scope of that concept.

When the read-only concept is violated, and implementations start scribbling
over _state_ of sessions that are in the cache during resumption
handshakes, it may result in problems such as these:

  CVE-2010-3864     http://www.openssl.org/news/secadv_20101116.txt 
  CVE-2010-4180     http://www.openssl.org/news/secadv_20101202.txt

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Sat, 7 Jun 2014 07:58:56 -0700

> handshakes, it may result in problems such as these:

What about this solution: separate TLS into a handshake and transport.
The handshake computes a connection key associated with the ticket,
then the transport computes a transport key based on that key and some
conceptually separate random data from both sides exchanged in the
handshake. When the transport is exhausted or we resume, the random
numbers change, but the connection key does not.

> _______________________________________________
> 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: "Salz, Rich" <[email-masked]>
Date: Sat, 7 Jun 2014 11:11:58 -0400

> What about this solution: separate TLS into a handshake and transport.

That's a very interesting idea.  The "HTTP/1.1 update" did that, turning RFC2616 into something like seven separate, albeit interlocked, RFC's.

	/r$

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 7 Jun 2014 08:41:08 -0700

> numbers change, but the connection key does not.

To some extent TLS already does try to make this separation, with
separate "TLS Record Protocol" (Section 6) and "TLS Handshaking
Protocols" (Section 7) with the handshake protocol establishing a
Master Secret for the entire session which is then used to derive
distinct record keys every time you reconnect (resume) in the same
session, with diversity provided by the random values. So, arguably,
TLS already behaves this way, with the exception of dealing with
cryptographic exhaustion of the transport keys (e.g., GCM counter
rollover).

MT's basic suggestion is to fix the cryptographic exhaustion
problem by having a signal to re-generate new transport level keys
from the Master Secret. AFAIK this doesn't require any new random
exchange because you already have existing random values that
provide per-connection diversity, so you just need to generate new
crypto keys, e.g., by cranking the PRF again starting with the PRF
and the random values and some sort of iteration count and doesn't
require any conceptual changes to the TLS session cache model
of the kind that Martin Rex is discussion.

Where things get interesting is that this solely addresses exhaustion
but not PFS [0] I.e., as long as the Master Secret is stored somewhere
(e.g., the session cache) then an attacker who recovers it can
recover all the traffic keys. Traditionally, if you renegotiate without
resumption (i.e., do a fresh key exchange), then you can address
this issue, but if we remove renegotiation, that option is no longer
available. That leaves us with a number of options:

- Tell people they just need to reconnect if they want to limit the
   exposure of a given session (i.e., do nothing).

- Provide a mechanism for re-keying the connection in a way that
  allows you to destroy the previous keys [1]. However, this still
  runs afoul of the fact that the Master Secret needs to be available
  to generate the connection keys. You can deal with this in two
  major ways:

  (a) Tell people not to use resumption (i.e., not to store the MS in the
        session cache) if they want to provide this feature.
  (b) Change the value stored in the session cache so it can only be
        used to make new connections but not to decrypt old ones.
        AFAIK this requires being willing to change the session cache [2]

Or perhaps there's some clever idea I haven't thought of...

Best,
-Ekr

[0] Maybe we need a new term other than PFS for this particular
security feature.

[1] E.g., have a per-connection "Connection Master Key" generated
from the MS and then used to generate the traffic keys. When you
initially connection, you would compute CMS[0] = PRF(MS, Randoms)
and then do Traffic Keys = PRF(CMS[0], ...). Then when the keys
were exhausted you would do CMS[1] = PRF(CMS[0], ...) and recompute
the traffic keys with CMS[1].  Since the PRF is notionally irreversible,
an attacker with access to the keys after the key change couldn't
decrypt old traffic.

[2] Vigorous handwaving: the trivial thing to do is just to have MS[0],
MS[1], MS[2], etc. where every time you resume you generate the next
generation MS and destroy the old one. Obviously this requires changing
the session cache data, which is undesirable for the reasons indicated
by Martin Rex.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 7 Jun 2014 08:49:55 -0700

On Sat, Jun 7, 2014 at 8:11 AM, Salz, Rich <[email-masked]> wrote:

> That's a very interesting idea.  The "HTTP/1.1 update" did that, turning
> RFC2616 into something like seven separate, albeit interlocked, RFC's.

As I noted in my response to Watson, TLS does already attempt to
make this split inside the RFC (Sections 6 and 7) so this seems like
more a document structure question than a technical one. IIRC when
HTTP did this, it was partly motivated by concerns that the document
was getting unwieldy and indeed RFC 2616 is quite a bit larger than
TLS (176 versus 104 pages).

As part of what we are trying to do with TLS 1.3 is to remove stuff
(my local draft with the initial non-AEAD removal is down to 94 pages)
I'd prefer to keep everything in one place, at least, for now.

Best,
-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 09 Jun 2014 09:34:20 +0200

> MT's basic suggestion is to fix the cryptographic exhaustion

Could somebody elaborate on what is that issue and why does it need to
be solved? (it is not even mentioned in the TLS 1.3 charter) As someone
who follows the mailing list that proposal comes out of the blue with no
context whatsoever.

regards,
Nikos

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Jun 2014 11:17:19 -0700

> who follows the mailing list that proposal comes out of the blue with no

I think that this has been covered in the thread, but piecemeal:

* Renegotiation is a major source of security issues, both of the "we
screwed the TLS design up" sort and of the "my application didn't
realize that these things could change" sort.  There is a clear desire
to remove features that enable either sort of problem.

* Renegotiation is just more protocol complexity.  Removing it
potentially makes implementations simpler.

I think that either might be sufficient justification for removing the feature.

However, a number of use cases depend on renegotiation to achieve
their ends.  Of these, we have identified:

* mid-session client authentication, which uses renegotiation seems to
only be used in HTTP

* very long-lived connections, which require renegotiation to re-key
occasionally

The former we have decided to solve in HTTP.  As a side note, we just
decided to forbid renegotiation in HTTP/2.

The latter can be addressed by my proposal, or any of a number of mechanisms.

---

From: Andrei Popov <[email-masked]>
Date: Mon, 9 Jun 2014 18:49:56 +0000

Hi Martin,

> The former we have decided to solve in HTTP.
 
Are you referring to these I-Ds:
http://tools.ietf.org/html/draft-thomson-httpbis-cant-00
http://tools.ietf.org/html/draft-thomson-tls-care-00

Httpbis-cant talks (rather vaguely) about using "realm" or "other challenge parameters" to select an appropriate client cert. I think client cert selection should be clearly specified before we can say that the mid-session client auth problem has been solved, and remove renegotiation from TLS 1.3.

It would be even better to solve this problem at the TLS layer, so that each application protocol does not need to come up with a separate solution. And avoiding the round-trips involved in establishing a TCP connection would be awesome, too. The current solution using renegotiation has both of these desirable properties.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Monday, June 9, 2014 11:17 AM
To: Nikos Mavrogiannopoulos
Cc: [email-masked]
Subject: Re: [TLS] Proposed text for removing renegotiation

On 9 June 2014 00:34, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> be solved? (it is not even mentioned in the TLS 1.3 charter) As 
> someone who follows the mailing list that proposal comes out of the 
> blue with no context whatsoever.

* Renegotiation is a major source of security issues, both of the "we screwed the TLS design up" sort and of the "my application didn't realize that these things could change" sort.  There is a clear desire to remove features that enable either sort of problem.

* Renegotiation is just more protocol complexity.  Removing it potentially makes implementations simpler.

However, a number of use cases depend on renegotiation to achieve their ends.  Of these, we have identified:

* mid-session client authentication, which uses renegotiation seems to only be used in HTTP

* very long-lived connections, which require renegotiation to re-key occasionally

The former we have decided to solve in HTTP.  As a side note, we just decided to forbid renegotiation in HTTP/2.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 9 Jun 2014 18:21:25 -0300

On Mon, Jun 9, 2014 at 3:49 PM, Andrei Popov <[email-masked]>
wrote:

> Httpbis-cant talks (rather vaguely) about using "realm" or "other
> challenge parameters" to select an appropriate client cert. I think client
> cert selection should be clearly specified before we can say that the
> mid-session client auth problem has been solved, and remove renegotiation
> from TLS 1.3.
>
> It would be even better to solve this problem at the TLS layer, so that
> each application protocol does not need to come up with a separate
> solution. And avoiding the round-trips involved in establishing a TCP
> connection would be awesome, too. The current solution using renegotiation
> has both of these desirable properties.
>

TLS still includes the Certificate Request message to indicate which client
certificates are being used. If we have an extension to allow clients to
say "I want to offer a cert, what cert do you want?", this can be used.

> screwed the TLS design up" sort and of the "my application didn't realize
> that these things could change" sort.  There is a clear desire to remove
> features that enable either sort of problem.
>

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Jun 2014 14:28:15 -0700

> Httpbis-cant talks (rather vaguely) about using "realm" or "other challenge parameters" to select an appropriate client cert. I think client cert selection should be clearly specified before we can…

The selection problem is, as we discussed in Denver, worth addressing.
The short term fix in HTTP/2 will actually be to force these users
down to HTTP/1.1.  That's suboptimal, certainly, but it does fix the
immediate problem.

As far as the -cant draft goes, I simply haven't uploaded an updated
version after our discussion in Denver.  There's a work in progress
version on github:
http://martinthomson.github.io/drafts/draft-thomson-httpbis-cant.html

> It would be even better to solve this problem at the TLS layer, so that each application protocol does not need to come up with a separate solution. And avoiding the round-trips involved in establi…

I'm sympathetic to this, but if HTTP is the only one that wants this
particular feature, then we are better off leaving them to work around
this.  At least in my opinion.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Jun 2014 14:29:13 -0700

On 9 June 2014 14:21, Watson Ladd <[email-masked]> wrote:
> certificates are being used. If we have an extension to allow clients to say
> "I want to offer a cert, what cert do you want?", this can be used.

That would be the second draft that Andrei referenced.  Note that my
preference is to have the ability to unilaterally offer authentication
as a client in TLS 1.3.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 10 Jun 2014 10:19:59 +0200

> I think that this has been covered in the thread, but piecemeal:

Not in my opinion. The arguments being presented are very vague, as the
ones you quote below.

> to remove features that enable either sort of problem.

Could you please cite these security issues. In the 17 years of the
protocol I have only seen one.

> potentially makes implementations simpler.

Where do you base this conclusion? Have you implemented it and you found
it complex, or have you tried to model it in some formal model and was
impossible? Renegotiation, is one of the most simple parts of the
protocol (Martin Rex argued for that in a previous e-mail and I concur).
Your proposal to solve this "complexity" is more complex than the
current solution.

> I think that either might be sufficient justification for removing the feature.

Not to me. I believe that unless hard evidence of the problems are
presented, this call for action here is unwarranted.

regards,
Nikos

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 10 Jun 2014 10:53:32 -0400

> Could you please cite these security issues. In the 17 years of the protocol I have only seen one.

Which one are you omitting -- Marsh's  or triple-handshake?

What's the old quote, when there is nothing more to take away...  [1] In that light, then, can we remove renegotiation without unduly making things worse?  So far, it seems to be yes.

[1] http://www.quotationspage.com/quote/26979.html
--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]; Twitter: RichSalz

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 10 Jun 2014 18:04:18 +0200

> Which one are you omitting -- Marsh's  or triple-handshake?

The triple handshake identified many issues in TLS but no issue in the
renegotiation. Renegotiation cannot solve the protocol's vulnerability
the triple handshake exploits.

Nevertheless, you can see the importance of renegotiation in the triple
handshake attack  by checking the preconditions for the attack. The
authors on their website clarify on the vulnerabilities they identified
and quoting them for renegotiation: "During renegotiation, both the
server and client certificates can change. This is allowed by TLS (and
supported in its main implementations) but no definitive guidance is
given to applications on how to deal with such changes".

Mentioning the lack of application level guidance (for applications that
need and make use of it) as a reason to drop renegotiation, is a bit far
fetched.

regards,
Nikos

---

From: Watson Ladd <[email-masked]>
Date: Tue, 10 Jun 2014 14:04:19 -0300

> protocol I have only seen one.

Triple Handshake depends on renegotiation confusion in part.
> Your proposal to solve this "complexity" is more complex than the

Quick: what is the proper response when the Certificate changes
between a negotiation and a renegotiation?
What is the relation between the two connections? Can there ever be
sensible semantics for this?

Renegotiation makes reads block on writes, a problem for all
event-based systems. Exposing renegotiation to application level code
is hard.

Show me a formalization of renegotiation semantics, and I might be
convinced otherwise. But to say that it is
"not complex" belies the experience of implementors, theorists, and
the past 17 years of security

The only thing not complex about it is making a terrible
implementation that fails to do the right thing.

You are right this is not in the charter: security was not placed in
it, despite repeated failures on the part of this WG to assure that
data protected by TLS is not folded, spindled, mutilated, or read in
transit. The complexity of the TLS protocol and its resistance to
modeling is directly responsible for many of these flaws, while
encouraging the continued use and expansion of several rather poor

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 11 Jun 2014 10:45:04 +0200

> between a negotiation and a renegotiation?

That is on the application protocol to decide.

> event-based systems. Exposing renegotiation to application level code

It has been done already, and not only once. Could you provide evidence
of this hardness that you claim?

> convinced otherwise. 

I think it is up to the one proposing the change to provide evidence of
the contrary and there has been none so far. Otherwise we do things like
prove me TLS secure  combination or we drop it completely. Formal models
lag behind protocols.

> But to say that it is

It's good to know that you are representing them. Could you share your
experience with implementing or modeling TLS? Or at least cite some
document that backs up the claims that you make.

regards,
Nikos

---

From: Watson Ladd <[email-masked]>
Date: Wed, 11 Jun 2014 08:45:50 -0300

> That is on the application protocol to decide.

Always the wrong answer: we know more then the application layer
people do about security, just as the networking people know more than
we do about sending packets through the network.

> of this hardness that you claim?

Where has this been done?

As for the hardness, most applications expect a stream of bytes.
Renegotation is OOB data.

> prove me TLS secure  combination or we drop it completely. Formal models

You guessed what the next email from me when EKR posted his draft was
going to say. Since miTLS finished up this has been a reasonable
position: TLS 1.2 has fairly well understood security, so TLS 1.3
should be better, not worse. Or do you think that three attacks in
three years is acceptable?

But as for theory vs. practice, that is false: there have been secure
key exchange protocols since the dawn of cryptography. The reason the
protocols have been hard to analyze is gratuitous complexity: there is
no reason TLS could not have used a secure key exchange as IPSEC
eventually did.

Where is the usecase that needs renegotiation in TLS 1.3? I've not
seen it: we've provided alternatives for all of them. Why do you care
what we do to provide an easy protocol to analyze? If there is a case
for keeping renegotation, make it: don't a

> document that backs up the claims that you make.

Let's see: there's the discussion in the Triple Handshake paper of how
applications respond to these changes, the previous renegotiation bug,
virtually every paper on the TLS handshake until miTLS, etc. Can you
point to someone providing an adequate explanation of what
renegotation does?

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 11 Jun 2014 16:08:00 +0000

A decision on the proper place to do access control has nothing to do with the skill of implementers.

If a web server (or any service provider) doesn't know how to grant access to resources based on authenticated user identity, user attributes, resource attributes and access policy, then a perfect bug-free network stack is not going to help them.

If a "certificate changes", then either the application should have requested renegotiation synchronously or it should have asynchronously established conditions for when the stack renegotiates and registered to be notified when it happens.  The proper response to renegotiation is identical to the proper response to negotiating the first time.

"We know more than the application layer people" - pure hubris.  TLS/IPSEC practitioners should definitely know more about cryptography, which application developers should be able to largely ignore as a black box.  But access control to application resources is inherently an application function for which TLS library coding expertise is no substitute.

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Watson Ladd
Sent: Wednesday, June 11, 2014 7:46 AM
To: Nikos Mavrogiannopoulos
Cc: [email-masked]
Subject: Re: [TLS] Proposed text for removing renegotiation

> That is on the application protocol to decide.

Always the wrong answer: we know more then the application layer people do about security, just as the networking people know more than we do about sending packets through the network.

---

From: Andrei Popov <[email-masked]>
Date: Wed, 11 Jun 2014 19:37:01 +0000

Thanks Martin for pointing out the updated httpbis-cant I-D on github. It seems to provide the same certificate filtering facilities as the CertificateRequest.

There are other significant problems with the removal of renegotiation from TLS 1.3 (please correct me if I'm missing something):
1. An existing HTTP/1.1 server cannot take advantage of TLS 1.3 if TLS client auth is required. This is because an existing HTTP/1.1 server is not aware of httpbis-cant.
2. An HTTP/2 server requires an updated TLS stack with tls-care support in order to perform TLS client auth. This is because HTTP/2 prohibits renegotiation.
3. Even with the updated TLS stack in place, an HTTP/2 server cannot negotiate TLS 1.2 and earlier if TLS client auth is required. This is because TLS 1.2 and earlier would send the client cert in the clear, which is bad for client privacy.
4. Without renegotiation, TLS client auth requires additional round-trips to establish a new TCP connection.

Perhaps the fundamental problem is that httpbis-cant introduces a client authentication challenge in HTTP that cannot be satisfied at the HTTP layer. This breaks the protocol layering, and causes the types of hard-to-manage dependencies listed above.

Even if httpbis-cant and tls-care both become RFCs, and get commonly implemented, and get widely deployed, I believe that the removal of renegotiation from TLS 1.3 creates more problems than it solves.

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, June 9, 2014 2:28 PM
To: Andrei Popov
Cc: Nikos Mavrogiannopoulos; [email-masked]
Subject: Re: [TLS] Proposed text for removing renegotiation

The selection problem is, as we discussed in Denver, worth addressing.
The short term fix in HTTP/2 will actually be to force these users down to HTTP/1.1.  That's suboptimal, certainly, but it does fix the immediate problem.

As far as the -cant draft goes, I simply haven't uploaded an updated version after our discussion in Denver.  There's a work in progress version on github:
http://martinthomson.github.io/drafts/draft-thomson-httpbis-cant.html

> It would be even better to solve this problem at the TLS layer, so that each application protocol does not need to come up with a separate solution. And avoiding the round-trips involved in establi…

I'm sympathetic to this, but if HTTP is the only one that wants this particular feature, then we are better off leaving them to work around this.  At least in my opinion.

---

From: Andrei Popov <[email-masked]>
Date: Wed, 11 Jun 2014 19:41:53 +0000

In any case, the triple handshake vulnerability has to be fixed, at least in TLS1.2 and below. The same fix would likely apply to TLS1.3, so IMHO triple handshake does not necessitate the removal of renegotiation from TLS1.3.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Nikos Mavrogiannopoulos
Sent: Tuesday, June 10, 2014 9:04 AM
To: Salz, Rich
Cc: [email-masked]
Subject: Re: [TLS] Proposed text for removing renegotiation

> Which one are you omitting -- Marsh's  or triple-handshake?

The triple handshake identified many issues in TLS but no issue in the renegotiation. Renegotiation cannot solve the protocol's vulnerability the triple handshake exploits.

Nevertheless, you can see the importance of renegotiation in the triple handshake attack  by checking the preconditions for the attack. The authors on their website clarify on the vulnerabilities they identified and quoting them for renegotiation: "During renegotiation, both the server and client certificates can change. This is allowed by TLS (and supported in its main implementations) but no definitive guidance is given to applications on how to deal with such changes".

Mentioning the lack of application level guidance (for applications that need and make use of it) as a reason to drop renegotiation, is a bit far fetched.

regards,
Nikos

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Jun 2014 13:01:41 -0700

To establish a bit more context here: the consensus in HTTPbis is to
provide a mechanism whereby servers are able to downgrade to HTTP/1.1
for the purposes of corner cases that are only properly supported by
HTTP/1.1.

Aside from some interesting legacy scenarios, client authentication
was considered a major reason for this feature.  We decided not to
adopt something like the -cant draft at the current time, since the
more generic capability was also needed.

> 1. An existing HTTP/1.1 server cannot take advantage of TLS 1.3 if TLS client auth is required. This is because an existing HTTP/1.1 server is not aware of httpbis-cant.

Correct.  That makes something like -cant a prerequisite of an upgrade
to TLS 1.3 for those servers.

> 2. An HTTP/2 server requires an updated TLS stack with tls-care support in order to perform TLS client auth. This is because HTTP/2 prohibits renegotiation.

This can be worked around.  In fact, the proposed text permits
renegotiation in TLS 1.2 (there is no "earlier" here because we
prohibit the use of earlier versions) prior to starting HTTP/2:

https://github.com/http2/http2-spec/pull/514/files#diff-8894168382f6487e5e38c4306e613a88R3430

(This isn't in the main spec due to a dependency issue, that text
captures the established consensus from the most recent interim
meeting.)

> 3. Even with the updated TLS stack in place, an HTTP/2 server cannot negotiate TLS 1.2 and earlier if TLS client auth is required. This is because TLS 1.2 and earlier would send the client cert in…

See above workaround.  The cost there is an additional round trip (if
you do false start, that is, it's a lot more without).

> 4. Without renegotiation, TLS client auth requires additional round-trips to establish a new TCP connection.

Correct.

---

From: Andrei Popov <[email-masked]>
Date: Thu, 12 Jun 2014 00:22:15 +0000

> the consensus in HTTPbis is to provide a mechanism whereby servers are able to downgrade to HTTP/1.1 for the purposes of corner cases that are only properly supported by HTTP/1.1.
I can't help noticing that this seems to directly contradict the #1 item on the HTTPbis WG charter:
" The Working Group's specification deliverables are:
 * A document (or set of documents) that is SUITABLE TO SUPERCEDE RFC 2616 as
 the definition of HTTP/1.1 and move RFC 2817 to Historic status"
But I guess this is up to the HTTPbis WG to discuss:)

> https://github.com/http2/http2-spec/pull/514/files#diff-8894168382f6487e5e38c4306e613a88R3430 
There are at least two protocol layering violations in this text, which I think will cause problems:
1) Preventing the use of renegotiation in response to a request for a specific protected resource, and
2) Constraining the TLS cipher suites to be used with HTTP/2.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Wednesday, June 11, 2014 1:02 PM
To: Andrei Popov
Cc: Nikos Mavrogiannopoulos; [email-masked]
Subject: Re: [TLS] Proposed text for removing renegotiation

To establish a bit more context here: the consensus in HTTPbis is to provide a mechanism whereby servers are able to downgrade to HTTP/1.1 for the purposes of corner cases that are only properly supported by HTTP/1.1.

Aside from some interesting legacy scenarios, client authentication was considered a major reason for this feature.  We decided not to adopt something like the -cant draft at the current time, since the more generic capability was also needed.

> 1. An existing HTTP/1.1 server cannot take advantage of TLS 1.3 if TLS client auth is required. This is because an existing HTTP/1.1 server is not aware of httpbis-cant.

Correct.  That makes something like -cant a prerequisite of an upgrade to TLS 1.3 for those servers.

> 2. An HTTP/2 server requires an updated TLS stack with tls-care support in order to perform TLS client auth. This is because HTTP/2 prohibits renegotiation.

This can be worked around.  In fact, the proposed text permits renegotiation in TLS 1.2 (there is no "earlier" here because we prohibit the use of earlier versions) prior to starting HTTP/2:

(This isn't in the main spec due to a dependency issue, that text captures the established consensus from the most recent interim
meeting.)

> 3. Even with the updated TLS stack in place, an HTTP/2 server cannot negotiate TLS 1.2 and earlier if TLS client auth is required. This is because TLS 1.2 and earlier would send the client cert in…

See above workaround.  The cost there is an additional round trip (if you do false start, that is, it's a lot more without).

Correct.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 11 Jun 2014 22:17:27 -0300

> If a web server (or any service provider) doesn't know how to grant access to resources based on authenticated user identity, user attributes, resource attributes and access policy, then a perfect…

Well, they do know how to grant access based on authenticated user
identity. What they don't know how to do is deal with portions of a
request being made with one identity, other portions with another.

> If a "certificate changes", then either the application should have requested renegotiation synchronously or it should have asynchronously established conditions for when the stack renegotiates and…

Name one program that actually enforces this, or a TLS implementation
that permits it, except by banning renegotiation entirely.

> "We know more than the application layer people" - pure hubris.  TLS/IPSEC practitioners should definitely know more about cryptography, which application developers should be able to largely ignor…

Yes, but we can make the job of the application much easier by
restricting the transformations that can happen. Applications are
mostly unaware that responses could be split across authentication
levels. That's why we had the renegotiation fix.

Things can get even worse: if I want to restrict a resource to some
ciphersuites, not others, this can be evaded by renegotiation if the
first ciphersuite is broken.

The issue is that the state transitions in renegotiation aren't
clearly explained or cleanly exposed to applications by most TLS
stacks. At this point, given the enormous number of applications using
and that should be using TLS, the fact that historically most TLS
stacks and applications using TLS have gotten this wrong, I don't see
stay the course as a reasonable option. Either we clean up
renegotiation to the point where it can be useful, or we throw it out.

Sincerely,
Watson Ladd

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Jun 2014 19:27:26 -0700

> But I guess this is up to the HTTPbis WG to discuss:)

That particular goal has been met with the publication of RFCs 7230
through 7235.

> 1) Preventing the use of renegotiation in response to a request for a specific protected resource, and

The renegotiation is a blanket ban, not conditional in the manner you
describe.  Arguably, renegotiation triggered by a request to a
specific protected resource is a far worse layering violation.

> 2) Constraining the TLS cipher suites to be used with HTTP/2.

I can't agree that this is necessarily a layering violation.  Though
the text recommends a violation, it also describes a method that does
not require a layering violation.  That is, if you consider the
interface to TLS to permit the passage of information about the active
cipher suite.

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 12 Jun 2014 16:12:24 +0000

That's a good rationale for saying TLS implementations SHALL NOT renegotiate unless requested or enabled by the application.  If the API doesn't provide a way to request/enable, then the stack shouldn't do it behind the app's back.

> Either we clean up renegotiation to the point where it can be useful, or we throw it out.

+1.  That's different from saying throw it out, period.

-----Original Message-----
From: Watson Ladd [mailto:[email-masked]] 
Sent: Wednesday, June 11, 2014 9:17 PM
To: Kemp, David P.
Cc: [email-masked]
Subject: Re: [TLS] Proposed text for removing renegotiation

> If a web server (or any service provider) doesn't know how to grant access to resources based on authenticated user identity, user attributes, resource attributes and access policy, then a perfect…

Well, they do know how to grant access based on authenticated user identity. What they don't know how to do is deal with portions of a request being made with one identity, other portions with another.

> If a "certificate changes", then either the application should have requested renegotiation synchronously or it should have asynchronously established conditions for when the stack renegotiates and…

Name one program that actually enforces this, or a TLS implementation that permits it, except by banning renegotiation entirely.

> "We know more than the application layer people" - pure hubris.  TLS/IPSEC practitioners should definitely know more about cryptography, which application developers should be able to largely ignor…

Yes, but we can make the job of the application much easier by restricting the transformations that can happen. Applications are mostly unaware that responses could be split across authentication levels. That's why we had the renegotiation fix.

Things can get even worse: if I want to restrict a resource to some ciphersuites, not others, this can be evaded by renegotiation if the first ciphersuite is broken.

The issue is that the state transitions in renegotiation aren't clearly explained or cleanly exposed to applications by most TLS stacks. At this point, given the enormous number of applications using and that should be using TLS, the fact that historically most TLS stacks and applications using TLS have gotten this wrong, I don't see stay the course as a reasonable option. Either we clean up renegotiation to the point where it can be useful, or we throw it out.

Sincerely,
Watson Ladd

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

---

From: David Holmes <[email-masked]>
Date: Thu, 12 Jun 2014 16:20:17 +0000

Some field data here.

Our load-balancers/SSL terminators let customers set a time interval for renegotiation (the default is never). 

We retain support customers for a period of time and have the ability to grep through customer configurations.

Over the previous 90 or 180 days (or whatever our retention period is) there are 33 customers using renegotiation (on 56 hosts). This is approximately 0.5% of the customers.

Of those hosts:
* The selected interval values range from 3 seconds (!!!) to 86400 - with an average being around 3600 seconds.
* Lots of 10-second renegotiation intervals as well.
* Seems to be a slight preference to the Financial vertical.

I'm not suggesting that this data moves the conversation about renegotiation one way or the other.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 12 Jun 2014 09:35:15 -0700

On Thu, Jun 12, 2014 at 9:20 AM, David Holmes <[email-masked]> wrote:

> Over the previous 90 or 180 days (or whatever our retention period is)
> there are 33 customers using renegotiation (on 56 hosts). This is
> approximately 0.5% of the customers.
>
> Of those hosts:

Do you have any idea why they want this?

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Jun 2014 09:50:26 -0700

> I'm not suggesting that this data moves the conversation about renegotiation one way or the other.

It certainly is good data that some/many of your customers (who I believe could be labelled as "typical") have little understanding of understanding what renegotiation is for. To me, that supports the "scrap it" argument.

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Thu, 12 Jun 2014 20:45:27 +0300

> Do you have any idea why they want this?

Maybe the Bruce said something about needing to regularly replace keys in “Applied Cryptography”.

The financial market also suggests some security consultant recommending setting the values.

3600 is actually a pretty fine value, as you would for the most part never see a renegotiation. Of course, configuring this by traffic volume would be even better.

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Jun 2014 11:05:40 -0700

> Maybe the Bruce said something about needing to regularly replace keys in

If rekeying is the reason, then the proposal I made should address
that adequately.

---

From: David Holmes <[email-masked]>
Date: Thu, 12 Jun 2014 18:22:09 +0000

ekr

➢ Do you have any idea why they want this?

The data points we have on “why” are the following:

1. low-bandwidth connections from automated teller machines (ATM) that can last for days or even weeks.
2. sites that start “open” but will require renegotiation w/ client cert when you try to enter a protected area.
3. infrastructure pieces use iQuery over TLS and these renegotiate periodically.

One could also look at the previous stat like this:

99.5% of the load-balancing customers do not use renegotiation.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Jun 2014 11:34:23 -0700

> 3. infrastructure pieces use iQuery over TLS and these renegotiate periodically.

That suggests 1. rekeying 2. client auth'n 3. rekeying (I think)

---

From: David Holmes <[email-masked]>
Date: Thu, 12 Jun 2014 20:51:28 +0000

> That suggests 1. rekeying 2. client auth'n 3. rekeying (I think)

Yes.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 13 Jun 2014 10:42:57 +0200

> we do about sending packets through the network.

Sorry, but I don't believe you understand the issue. Authentication is
to the application layer to decide. The secure transport protocol cannot
know or guess when and if authentication is desired by the upper
protocols. TLS should determine the algorithms and the methods, but the
upper protocols should set the timing and the allowed combinations. It
may be very legitimate to switch my user-certificate to access a
different web page; that cannot be mandated by TLS.

> Where has this been done?

I'd suggest you to check existing TLS implementations, or read the
discussion in the triple handshake paper (section II).

> Renegotation is OOB data.

What is the issue with that?

> three years is acceptable?

I don't think anyone would disagree with what you say here. But you are
avoiding to reply to the point. Was the new proposal you endorse proven
secure, or do we replace the old method, -that you claim is insecure-
with yet another method that will be proven insecure in few years?

> seen it: we've provided alternatives for all of them.

I don't buy the we have provided alternatives for all of them, because
you fail to show the issue that is so grave that requires throwing out
renegotiation, and re-inventing it.

>  Why do you care
> for keeping renegotation, make it:

Sorry, protocol design doesn't work like that. If you want to change or
remove something, you need to make a case for that, and it is up to you
to make solid arguments. Making a change an basing it on arguments like,
(1) everyone knows that, (2) this paper supports my opinion -but it
doesn't-, doesn't give any credibility to your proposal.

Maybe you are right, but unless you make your case with solid arguments,
you haven't convinced me.

> applications respond to these changes,

Which changes do you refer to, and which discussion. The paper as I read
it, makes no claims that renegotiation is overly complex or cannot be
modeled. On the contrary, it is mentioned that it is already modeled in
mitls.

>  the previous renegotiation bug,

It was addressed long time ago.

> point to someone providing an adequate explanation of what

This is not a citation, you could replace it with "everyone knows that".
If you really have a point, because it is not of your own experience,
please cite it properly.

regards,
Nikos

---

From: Watson Ladd <[email-masked]>
Date: Fri, 13 Jun 2014 08:34:29 -0300

> different web page; that cannot be mandated by TLS.

Sure, but then we should make clear that the upper-level protocol
should control when renegotiation happens.

Right now it's a free-for-all: you can change the authentication state
repeatedly in the course of reading a request.
As a result, when the application checks what the authentication state
is there is a TOCTOU problem.

The renegotiation fix kind of solves this problem: it takes data from
the first connection and links it to the second.
> What is the issue with that?

The issue is the following: most applications do something like this
parse_request(conn)
check_if_request_authorized(conn)

This assumes that the authentication state doesn't change in between
the two lines, or midway through the parse.
With renegotiation it can.

Furthermore, renegotiation makes writes block on reads. That can cause
pain for event based systems.
> with yet another method that will be proven insecure in few years?

What new proposal have I endorsed? No, you do the work to show your
protocol is secure.
Up until now, we haven't, and users have paid the price.

(If we eliminate renegotation, clearly this cannot be less secure. If
we add key rotation, assuming we do it sanely, there is fairly clearly
not a problem.)

> It was addressed long time ago.

I don't think you understand the point I'm trying to make: it's not
that I can sit down and make an attack taking advantage of
renegotation. It's that renegotation is so complex that applications
don't understand how to use it, and so it's very difficult to ensure
that we've provided the right semantics, and hard to determine how
implementations should deal with it.

With the Finished message it's a different issue: analyzing with
Finished is a pain, because the master-secret gets used as is.

With the core handshake it's a third issue: the standard key agreement
semantics have never been provided, and they should be.

I don't care too much about renegotiation: the handshake fixes,
maintaining the security of the new handshakes, and fixing the
finished message are more important.

> If you really have a point, because it is not of your own experience,

Go to eprint.iacr.org. Search TLS:
http://eprint.iacr.org/2013/339.pdf "we do not model renegotation/resumption"
http://eprint.iacr.org/2012/630.pdf Analyzes the renegotation fix, a
full 3 years after the fix was proposed and adopted, and TLS does not
meet strongest security model.
http://eprint.iacr.org/2014/020.pdf Renegotation isn't mentioned.

I did skip over a few papers but the message is clear: renegotiation
is not currently amenable to analysis.

Sincerely,
Watson Ladd

---

From: Steve Checkoway <[email-masked]>
Date: Fri, 13 Jun 2014 13:44:11 -0400

> With renegotiation it can.

Although I'm leaning toward removing renegotiation (and potentially adding
rekeying or authentication), I'm not sure your example demonstrates an
issue. Regardless of the authentication state during parse_request, the
relevant issue is is the other side authorized at the point of the
check_if_request_authorized.

Where do you see a TOCTTOU violation?

 --
Steve Checkoway

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 13 Jun 2014 14:09:57 -0400

Ø  Where do you see a TOCTTOU violation?

I don’t think it’s guaranteed that there’s a violation, but it is very hard to get this right. Compared to, say, filesystem operations on a local operating system, things are sequential and atomic; a process can’t do setuid() while open() is checking to see if the process has the required permission. And also the kernel ALWAYS knows the identity of the program. This is different from network/web applications, which are often not expecting identity checks, and where the “framework runtime” is doing things while the business logic is processing a request, often in the name of speedXXXXX better user experience.

                /r$

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

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 13 Jun 2014 14:12:32 -0400

Arg.  Are “often not expecting identity CHANGES,”

From: Salz, Rich [mailto:[email-masked]]
Sent: Friday, June 13, 2014 2:10 PM
To: Steve Checkoway; [email-masked]
Subject: Re: [TLS] Proposed text for removing renegotiation

                /r$

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 17 Jun 2014 09:36:36 +0200

> With renegotiation it can.

Indeed, but this is an easily unsolvable issue. That can be easily
avoided on the implementation side (and gnutls is does not allow that).
I have numerous times asked to clarify and better specify this part on
the past.

> pain for event based systems.

I don't understand what do you make by makes writes block on reads.
Renegotiation is the same a negotiation in TLS. The same issues that
exist in the TLS handshake will exist in the rehandshake. Nevertheless,
I've used many even-based systems with TLS with no issue.

> What new proposal have I endorsed?

The whole thread is about dropping renegotiation _and_ replacing with a
mechanism proposed by Martin Thompson.

>  No, you do the work to show your
> protocol is secure.
[...]
> is not currently amenable to analysis.

Interesting observation. However, the fact that renegotiation has not
been modeled in some papers doesn't reveal much except that the formal
protocol verification lags behind protocol design. If you check the
papers that you reference you'll notice that it is not only
renegotiation that they don't model. The first one doesn't even model
ciphersuite negotiation which is the basis of the protocol. The second
does mention that renegotiation can be modified to avoid a stronger
adversary, i.e., an adversary that can learn the previous session keys.
That's an interesting paper, but whether we really need to protect
against this adversary is really up to discussion.

Most often in academic papers (with the exception of mitls work) they
simply model a single ciphersuite and prove it secure; then in the next
month you see an new attack on the same ciphersuite that was proven
secure, because the majority of the protocol interactions were ignored.
That does not show that we need to drop all the protocol options and
only allow for RSA-AES-CBC for example (which was proven secure numerous
times prior it was broken). If we had followed that path and dropped
ciphersuite negotiation, renegotiation, and session resumption, only to
allow the "proven" secure options, now TLS would be broken and we
wouldn't have a way to fix it.

regards,
Nikos

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 17 Jun 2014 16:56:30 -0400

On 06/17/2014 03:36 AM, Nikos Mavrogiannopoulos wrote:
> Indeed, but this is an easily unsolvable issue. 

Do you mean "easily solvable" here?

> That can be easily

Do you have a suggestion for how we could clarify and better specify
this part?  Maybe it's worth crafting that into a counterproposal that
could be weighed against the current "remove renegotiation" proposal.

I realize that we frequently claim we "don't do API" here, and the issue
of how well application developers actually deal with connection
property changes comes close to the API of any given TLS implementation.

But I suspect most application developers who use TLS don't understand
that the authentication state or cryptographic protections of the
connection may change mid-stream.  Of the minority that does understand
that this state may change, i suspect that many of them don't actually
handle the situation well (if at all).

if we want to avoid this on the implementation side, do we need more
guidance to implementers of TLS stacks?  or guidance for
application-layer users of those stacks?  or both?

	--dkg

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 19 Jun 2014 12:26:48 +0200

Yes.

> could be weighed against the current "remove renegotiation" proposal.

My counter-proposal would be:
1. Removing the Note "If a rehandshake occurs while data is flowing on a
connection, the communicating parties may continue to send data using
the old CipherSpec."

2. Adding the text: "During the handshake process implementations SHALL
NOT allow application protocol data exchange. Implementations SHALL
terminate the session if application protocol data is received." (in
DTLS that data may arrive due to network errors so they should be
quietly discarded.

3. Adding the text "Since the authentication credentials may change
during a renegotiation the upper layers must be notified of either the
new negotiation process or any identity change."

That would make renegotiation a strictly inband process, and
applications would be able to distinguish traffic before and after a new
negotiation.

regards,
Nikos

---

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

> applications would be able to distinguish traffic before and after a new

That sounds strictly worse than what we have today.

Points 1&2 render the connection unusable, something that many
applications can't have.  In many respects - other than TCP congestion
window warmup perhaps - this is equivalent to Brian's proposal to
remove renegotiation and replace it with nothing, forcing people to
make new connections.

And the main point, which is that it's not the lack of a notification
API for renegotiation that causes the issue, it's the fact that it can
happen at all.

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 19 Jun 2014 22:06:17 +0000

> And the main point, which is that it's not the lack of a
> notification API for renegotiation that causes the issue,
> it's the fact that it can happen at all.

If there is not general agreement on what "the issue" is, there won't be agreement on how to solve it.  If "the issue" is "we don't like renegotiation", then of course no solution other than eliminating renegotiation will solve it.

But if the issue is that applications on each side of a TLS connection don't have a common understanding of what parameters have been negotiated and when they become effective, then an API that supports data semantics identical to "Close and Open TCP" without actually negotiating a new TCP connection is a valid solution.

An application must be guaranteed that all data sent or received prior to renegotiation uses the old set of parameters and all data sent or received after uses the new set.  The TLS library should arrange for that to happen such that the data flowing in one direction (written on the initiating side) flows continuously over the wire, slowed only by the TLS handshake bytes transmitted in that direction.  Data in the other direction is delayed as necessary to sync with the transition.

Note 2 may be overly restrictive if "handshake process" is interpreted to include any round trips.  It should include only messages that trigger the use of new parameters; there is no reason to block data while sending setup messages that have not yet taken effect.

>> applications would be able to distinguish traffic before and after a 
>> new negotiation  ---> becomes effective <---.

That is the requirement.

Dave

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Thursday, June 19, 2014 11:28 AM
To: Nikos Mavrogiannopoulos
Cc: [email-masked]
Subject: Re: [TLS] Proposed text for removing renegotiation

On 19 June 2014 03:26, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> 1. Removing the Note "If a rehandshake occurs while data is flowing on 
> a connection, the communicating parties may continue to send data 
> using the old CipherSpec."
>
> 2. Adding the text: "During the handshake process implementations 
> SHALL NOT allow application protocol data exchange. Implementations 
> SHALL terminate the session if application protocol data is received." 
> (in DTLS that data may arrive due to network errors so they should be 
> quietly discarded.
>
> applications would be able to distinguish traffic before and after a 
> new negotiation.

Points 1&2 render the connection unusable, something that many applications can't have.  In many respects - other than TCP congestion window warmup perhaps - this is equivalent to Brian's proposal to remove renegotiation and replace it with nothing, forcing people to make new connections.

And the main point, which is that it's not the lack of a notification API for renegotiation that causes the issue, it's the fact that it can happen at all.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 20 Jun 2014 09:32:07 +0200

On Thu, 2014-06-19 at 08:28 -0700, Martin Thomson wrote:
> applications can't have.

Could you elaborate on the applications that will be affected by such
change? I've never seen any such applications, and in fact for the 99%
of the renegotiation uses (e.g., the web) the renegotiation operation
would be identical before and after my proposed change. The only
applications that could potentially interleave TLS application and
handshake data are TLS-based VPNs, and there aren't any that do that
(and they could if they are required to, that's why there is a SHALL NOT
there instead of must).

The other advantage is the symmetricity of TLS handshake and
re-handshake. By allowing application data during the re-handshake one
opens the door for allowing application data during the handshake, if an
implementer doesn't distinguish the two perfectly symmetric options.

>   In many respects - other than TCP congestion

I disagree with this evaluation, as there is no data to back that up.

regards,
Nikos

---

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

On 20 June 2014 00:32, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> would be identical before and after my proposed change.

I'm concerned about applications that rely on renegotiation for
rekeying purposes, not the web scenarios.  For instance, those small
number of F5 users that have set a renegotiation timer (see David's
email earlier in the thread).

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 23 Jun 2014 14:07:52 +0200

> email earlier in the thread).

How would these applications be affected? Do you know whether the F5
implementation interleaves the re-handshake with application data? In
any case I don't see how can this be used as an argument for removing
renegotiation instead of what I proposed. In both cases (if we assume
that the F5 implementation does interleave application with handshake
data), the implementation would need to be updated.

regards,
Nikos

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Jun 2014 09:43:45 -0700

On 23 June 2014 05:07, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> How would these applications be affected?

Dead air is unacceptable for at least one application I'm aware of for
long-lived connections (and therefore occasional rekeying), and that
is server-to-server XMPP.

> Do you know whether the F5
> implementation interleaves the re-handshake with application data?

No.  Most likely scenarios is that it's not going to do anything other
than impose some extra latency on HTTP requests.  Though I'll point
out that some people do care about that quite a bit.