Subject: [TLS] Call for Consensus on removal of renegotiation

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 25 Jun 2014 18:34:44 +0000

We would like to see if there is consensus on removing renegotiation in TLS 1.3.  We had rough consensus at the interim to remove renegotiation. Please state your position by indicating preference for one of the following (we will have a separate consensus call to decide on rekey approach). 

1. Do you favor removing renegotiation from TLS 1.3 either with or without an additional facility for rekey?
2. Are you in favor of not removing renegotiation regardless of the addition of a separate rekey facility?

Please respond to the list by July 1, 2014.   

Thanks,

Joe
(for the chairs)

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 25 Jun 2014 14:47:11 -0400

> 2. Are you in favor of not removing renegotiation regardless of the addition of a separate rekey facility?

If we're supposed to select either 1 or 2, i wouldn't feel comfortable
with either one.

If we aren't providing an additional facility for re-keying, then i am
not OK with removing renegotiation.  TLS needs a way for high-traffic,
longstanding connections to stay up without "dead air" (as i think Sean
called it earlier).  So i can't choose (1).

OTOH, if we have a separate rekey facility, i think that the semantics
of TLS will be clearer (easier for application developers to understand
and work with; easier for cryptanalysts to evaluate) if we get rid of
renegotiation.  So i can't choose (2).

Maybe this question needs to be re-framed, or we need an option 0?

	--dkg

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 25 Jun 2014 20:03:06 +0000

> Maybe this question needs to be re-framed, or we need an option 0?

[Joe] to simplify:

1.  In favor of removing renegotiation
2.  In favor of removing renegotiation with the addition of rekey facility
3.  Not in favor of removing renegotiation 

(the first attempt combined 1 and 2)

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Jun 2014 13:20:45 -0700

> 3.  Not in favor of removing renegotiation

2 > 1 >> 3 > 4

>From a browser perspective, 1 would be OK: we simply don't have
connections that live that long.  But when you have long-lived
connections, rekeying is highly valuable.  It's also clear to me that
some users want to rekey more often than that even.

I don't think that there is any value in keeping renegotiation, but
having artificial constraints on what can change.  I think that it's
significantly easier to reason about *anything* where the things that
are immutable simply cannot change.

For my #4.... I'll note that the options don't include anything like
the poor-mans renegotiation: end the TLS session and make a new one on
the same underlying transport.  Is that intentional?  In case you
decide to poll that option, I think that it's strictly worse than
renegotiation due to the 'dead air' problem.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 25 Jun 2014 13:26:01 -0700

> called it earlier).  So i can't choose (1).

Probably a stupid and ignorant question; but what prevents
applications with this kind of requirement from creating a new
connection, negotiating a new key, and then switching to the new
connection when they're ready?

-- 
Colm

---

From: Russ Housley <[email-masked]>
Date: Wed, 25 Jun 2014 16:30:18 -0400

Please count me in camp 1.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 25 Jun 2014 23:39:07 +0300

> connection when they're ready?

Nothing. But that would require changing those applications. 

Before: The client opens a connection, calls the TLS library, and then transmits arbitrarily-much data for an arbitrarily-long time. If so much data has been transmitted that rekeying is warranted, The TLS library will do it transparently to the application.

After: The client opens a connection, calls the TLS library, and then transmits information. After a while, either a data count passes some limit, or a timer expires, and the application is informed by the TLS library that this connection can no longer be used. So the client opens a new connection and calls the TLS library again. Simple? Not really, because now we need to add to the application some session mechanism to bind the old and the new connections. Think telnet-over-ssl as an alternative to SSH. You don’t want to lose your environment and what you were just typing, right? This is a requirement from the application that didn’t exist before.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 25 Jun 2014 16:42:42 -0400

> Nothing. But that would require changing those applications.

Wouldn't they already have to change in order to use TLS 1.3?  Or would the underlying library switch to it, and then not do the magic rekey calls?

	/r$

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

---

From: Yoav Nir <[email-masked]>
Date: Wed, 25 Jun 2014 23:47:50 +0300

> Wouldn't they already have to change in order to use TLS 1.3?  Or would the underlying library switch to it, and then not do the magic rekey calls?

An application running on something like Apache can replace the OpenSSL library, and instantly get upgraded from supporting only SSLv3 and TLS 1.0 to support TLS 1.2 and AES-GCM and ECDHE.

If that application ever ran enough traffic that renegotiation for rekeying was needed, upgrading to the next OpenSSL that includes TLS 1.3 would not be as smooth.

BTW: This discussion is totally missing the other use of renegotiation - to move from server-authenticated to mutually-authenticated. Unless that need is addressed (by some mechanism), I can’t support removing renegotiation.

Yoav

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 25 Jun 2014 16:52:37 -0400

> If that application ever ran enough traffic that renegotiation for rekeying was
> needed, upgrading to the next OpenSSL that includes TLS 1.3 would not be as
> smooth.

Unless that next OpenSSL knew enough to do the re-key work. Hm. This would argue that Martin's approach is probably less disruptive than my preferred approach.

> BTW: This discussion is totally missing the other use of renegotiation - to
> move from server-authenticated to mutually-authenticated. Unless that
> need is addressed (by some mechanism), I can't support removing
> renegotiation.

I believe the consensus is to adopt http://datatracker.ietf.org/doc/draft-thomson-tls-care/ which I prefer to think of as "do have any idea who I am"

	/r$

---

From: Yoav Nir <[email-masked]>
Date: Thu, 26 Jun 2014 00:06:11 +0300

> Unless that next OpenSSL knew enough to do the re-key work. Hm. This would argue that Martin's approach is probably less disruptive than my preferred approach.

Even if OpenSSL knows enough to start a new connection, the application needs to be able to bind the old connection to the new, unless we add some kind of session management to TLS. But that would trade new complexity for old complexity, so I don’t think we want that.

> I believe the consensus is to adopt http://datatracker.ietf.org/doc/draft-thomson-tls-care/ which I prefer to think of as "do have any idea who I am”

I must have missed when they called consensus on that. In that case, I’m with the “remove it entirely (1)” camp. We use 128-bit ciphers today. Even with CBC, you will replace the client and the server long before you’ve encrypted so much that you need to rekey.  Periodic rekeying is something that auditors like, but is very rarely needed in HTTPS, SMTP and the like. I’m fine with forcing the few applications that need to to adapt.

Yoav

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 25 Jun 2014 17:08:07 -0400

> > I believe the consensus is to adopt http://datatracker.ietf.org/doc/draft-
> thomson-tls-care/ which I prefer to think of as "do have any idea who I am"
> 
> I must have missed when they called consensus on that.

Or equally likely just wishful thinking on my part.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Jun 2014 14:12:02 -0700

> I believe the consensus is to adopt http://datatracker.ietf.org/doc/draft-thomson-tls-care/ which I prefer to think of as "do have any idea who I am"

I wouldn't have characterized it as consensus...  But "do you have any
idea who I am" is the less critical piece of the puzzle.  I'd say that
http://tools.ietf.org/html/draft-thomson-httpbis-cant-00 - and
anything like it, is more important.  I've recently made a tweak to
that to remove the dependency on any TLS extension.  I've been sitting
on it, but I'll have -01 out in a few minutes.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 25 Jun 2014 14:17:44 -0700

On Wed, Jun 25, 2014 at 1:39 PM, Yoav Nir <[email-masked]> wrote:
> After: The client opens a connection, calls the TLS library, and then transmits information. After a while, either a data count passes some limit, or a timer expires, and the application is informed by the TLS library that this connection can no longer be used. So the client opens a new connection and calls the TLS library again. Simple?

This seems like a strawman argument. Why can't a library make
connections and hide that detail of the application? Of course a
library can, as database connection pool libraries do, for example.

-- 
Colm

---

From: Yoav Nir <[email-masked]>
Date: Thu, 26 Jun 2014 00:39:27 +0300

> library can, as database connection pool libraries do, for example.

I disagree. Suppose we did a telnet-over-tls protocol (yes, of course somebody’s already done it). 

When I’m logged in through telnet (or SSH, or telnet-over-tls), I enter some credentials, and I get an environment. It’s fine for the library to take over sockets and such, but the server has to (a) be convinced that the new connection is associated with the same user, and (b) associate the old environment with the new connection. 

I don’t see how you can do that without modifying telnet.  Can you?

Yoav

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 25 Jun 2014 14:45:31 -0700

> I don’t see how you can do that without modifying telnet.  Can you?

This too seems like a strawman; SSH does not use TLS, and
telnet-over-tls is not common. The requirements of securing
interactive logins differ enough from TLSs features that those
applications have found other solutions entirely.

-- 
Colm

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 25 Jun 2014 21:57:59 -0400

The web is more than HTTP; tls-care is global, http-cant is for some small part of the web :)

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Jun 2014 19:01:17 -0700

> The web is more than HTTP; tls-care is global, http-cant is for some small part of the web :)

That's true, but the key point of this is that the application
protocol needs a signal to cause a new connection to be created.  So
far, HTTP is the only application protocol that needs this; hence
-cant.

My point regarding -cant was that it can work without a TLS extension,
i.e., it works if the CertificateRequest is triggered on renego (<=
1.2) or clients can unilaterally authenticate (>= 1.3).

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 26 Jun 2014 09:14:01 +0200

> Please respond to the list by July 1, 2014.   

I don't understand how this got into the discussion of TLS 1.3. This was
never approved as part of the TLS 1.3 charter, so I believe that there
should be a re-charter to include changes like that. As it is now the
discussion on TLS 1.3 is moving wherever the wind blows.

regards,
Nikos

---

From: Hubert Kario <[email-masked]>
Date: Thu, 26 Jun 2014 06:49:56 -0400 (EDT)

----- Original Message -----
> From: "Yoav Nir" <[email-masked]>
> To: "Rich Salz" <[email-masked]>
> Cc: "<[email-masked]>" <[email-masked]>
> Sent: Wednesday, 25 June, 2014 11:06:11 PM
> Subject: Re: [TLS] Call for Consensus on removal of renegotiation
> 
> 
> > I believe the consensus is to adopt
> > http://datatracker.ietf.org/doc/draft-thomson-tls-care/ which I prefer to
> > think of as "do have any idea who I am”
> 
> I must have missed when they called consensus on that. In that case, I’m with
> the “remove it entirely (1)” camp. We use 128-bit ciphers today. Even with
> CBC, you will replace the client and the server long before you’ve encrypted
> so much that you need to rekey.  Periodic rekeying is something that
> auditors like, but is very rarely needed in HTTPS, SMTP and the like. I’m
> fine with forcing the few applications that need to to adapt.

Current FIPS states that you can't encrypt more than 64GiB with a single key
using AES-GCM. It's not a lot, and it is definetely in the realm of possibility
even for HTTPS (games, disk images), let alone actually long lived connections...

-- 
Regards,
Hubert Kario

---

From: [email-masked] (Martin Rex)
Date: Thu, 26 Jun 2014 16:08:57 +0200 (CEST)

Hubert Kario wrote:
> 
> Current FIPS states that you can't encrypt more than 64GiB with
> a single key using AES-GCM. It's not a lot, and it is definetely
> in the realm of possibility even for HTTPS (games, disk images),
> let alone actually long lived connections...

For some, 64 GigaBytes is at the small end already today.

I know folks who transfer database backups over TLS-protected
communiation links (i.e TeraByte(s) of data).

-Martin

---

From: [email-masked] (Martin Rex)
Date: Thu, 26 Jun 2014 16:30:44 +0200 (CEST)

> 3.  Not in favor of removing renegotiation 

(3) Leave it in the spec,  Make it a true option for implementors.
    with a guidance that clients might need it for interop, but should
    play safe (and nail down identities once they're established) by default

I never offered/exposed renegotiation at the API to application callers,
and since January 2010, I have the server-side reject renegotiation attempts
from clients.  But the installed base of _other_ servers that use
(or require) it is to large to be ignored, and I don't see it go away
that easily...

Everything that you change from TLSv1.0/1/2 toward v1.3 will add complexity
and require more code.  This applies not just to adding new features, but
also to axing existing features that may be in current use.

A TLSv1.3 spec that requires implementors to carefully avoid TLSv1.3 for
a number of commonly used TLSv1.0/1/2 features may be even harder to
sell than TLSv1.2 and IPv6.

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Thu, 26 Jun 2014 07:40:49 -0700

> 1. Do you favor removing renegotiation from TLS 1.3 either with or without an additional facility for rekey?

Remove renegotiation: we need a properly working rekey compatible with
session tickets.

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

---

From: Watson Ladd <[email-masked]>
Date: Thu, 26 Jun 2014 07:51:19 -0700

> discussion on TLS 1.3 is moving wherever the wind blows.

The TLS 1.3 charter didn't include security as a charter goal. It was
also very controversial: significant numbers of implementers indicated
that they wished the committee would deal with problems ignored for a
decade or two before trying to make something new.

Sincerely,
Watson Ladd

---

From: Yoav Nir <[email-masked]>
Date: Thu, 26 Jun 2014 18:48:33 +0300

On Jun 26, 2014, at 1:49 PM, Hubert Kario <[email-masked]> wrote:

> even for HTTPS (games, disk images), let alone actually long lived connections…

That number seemed suspiciously low, so I went and read SP-800-38D.

It recommends two different limits depending on the length of the IV.

For IVs that are constructed deterministically, but whose length is *not* 96 bits, the limit is 2^32 invocations. 2^32 invocations means 4 billion TLS records, which could be up to 16 Terabytes.

But that doesn’t matter anyway, because in TLS the recommendation is to create the nonce deterministically and the length *is* 96 bits, so the limit is 2^64 invocations. 

Even with 1-byte records, that’s more terabytes than we know what to do with.

So I stand by what I said earlier. Just because of volume, there is no reason to rekey an AES session.

Yoav

---

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

On Thu, Jun 26, 2014 at 6:48 PM, Yoav Nir <[email-masked]> wrote:

> For IVs that are constructed deterministically, but whose length is *not*
> 96 bits, the limit is 2^32 invocations. 2^32 invocations means 4 billion
> TLS records, which could be up to 16 Terabytes.
>

Sorry. That's 64 TB.

---

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

> So I stand by what I said earlier. Just because of volume, there is no reason to rekey an AES session.

That's true for TLS. DTLS has its record counter is limited to 2^48
bits, and that could require a rekey as it is often used for long-lived
VPN sessions. Of course this call is about TLS though.

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 26 Jun 2014 10:38:20 -0700

On Thu, Jun 26, 2014 at 10:32 AM, Nikos Mavrogiannopoulos <[email-masked]>
wrote:

> > For IVs that are constructed deterministically, but whose length is
> *not* 96 bits, the limit is 2^32 invocations. 2^32 invocations means 4
> billion TLS records, which could be up to 16 Terabytes.
> > But that doesn’t matter anyway, because in TLS the recommendation is to
> create the nonce deterministically and the length *is* 96 bits, so the
> limit is 2^64 invocations.
> VPN sessions. Of course this call is about TLS though
>

I would expect any decision made here to apply to DTLS as well.

-Ekr

---

From: Brian Hamon <[email-masked]>
Date: Thu, 26 Jun 2014 21:18:58 +0000

Over the past week, I've been watching for an answer to the question posed regarding how we deal with the situation where the server must examine some Application Data messages in order to determine whether client authentication is required.

Presently, this situation is handled by allowing an unauthenticated client to send some Application Data, then if client authentication is required, it will send a HelloRequest, starting renegotiation. During the subsequent handshake, the server sends a CertificateRequest and drops the connection if the client fails to authenticate and authorize.

I've seen the following concerns raised with this approach:

1) How does the client authentication persist (or not persist) in the face of session resumption?

2) If the answer to #1 is that yes, the authentication persists, then does the most-recently-supplied identity replace or aggregate with previous identities presented in the same session?

I worked through a number of possible alternatives where we separate client authentication completely from the handshake, and I think the solution lies down this path; however, before digging into those details, let me ask for the group's consensus on the two questions posed above.

I would argue that session resumption should revert the client's identity back to "unauthenticated". This avoids a lot of the complicated workarounds required for #2.

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Thursday, June 26, 2014 7:31 AM
To: Joseph Salowey (jsalowey)
Cc: <[email-masked]>
Subject: Re: [TLS] Call for Consensus on removal of renegotiation

Joseph Salowey (jsalowey) wrote:
> 
> 1.  In favor of removing renegotiation 2.  In favor of removing 
> renegotiation with the addition of rekey facility 3.  Not in favor of 
> removing renegotiation

I never offered/exposed renegotiation at the API to application callers, and since January 2010, I have the server-side reject renegotiation attempts from clients.  But the installed base of _other_ servers that use (or require) it is to large to be ignored, and I don't see it go away that easily...

Everything that you change from TLSv1.0/1/2 toward v1.3 will add complexity and require more code.  This applies not just to adding new features, but also to axing existing features that may be in current use.

A TLSv1.3 spec that requires implementors to carefully avoid TLSv1.3 for a number of commonly used TLSv1.0/1/2 features may be even harder to sell than TLSv1.2 and IPv6.

-Martin

---

From: Martin Thomson <[email-masked]>
Date: Thu, 26 Jun 2014 14:29:14 -0700

> I would argue that session resumption should revert the client's identity back to "unauthenticated". This avoids a lot of the complicated workarounds required for #2.

I hope that you realize that we're not talking about resumption right
at this moment.  There are some interactions with resumption, but I
think we're trying not to overcomplicate the issue by considering the
implications of those just yet.

That said, if you did mean renegotiation in the above statement.  I
don't think that making any recommendation to this effect will have
any material impact on the sorts of bugs we've seen with
renegotiation.  You can *say* that people should do this or that
because it's good practice, but I think that that is just wishful
thinking.

---

From: Brian Hamon <[email-masked]>
Date: Thu, 26 Jun 2014 21:38:08 +0000

Yes, I do understand this is a discussion of renegotiation, and I'm in basic agreement with your proposal. However, it does leave unaddressed the issue I presented regarding the loss of the ability of the server to postpone demanding client authentication until the contents of one or more ApplicationData messages are examined.

I was trying to gather a list of objections that some have expressed of the use of renegotiation to deal with this specific situation, and as far as I can recall the only ones dealt with resumption. Am I forgetting any others?

My main concern is that if your proposal is accepted, what is the solution for a server that must examine some ApplicationData in order to determine if client authentication is required?  

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Thursday, June 26, 2014 2:29 PM
To: Brian Hamon
Cc: [email-masked]; Joseph Salowey (jsalowey); <[email-masked]>
Subject: Re: [TLS] Call for Consensus on removal of renegotiation

> I would argue that session resumption should revert the client's identity back to "unauthenticated". This avoids a lot of the complicated workarounds required for #2.

I hope that you realize that we're not talking about resumption right at this moment.  There are some interactions with resumption, but I think we're trying not to overcomplicate the issue by considering the implications of those just yet.

That said, if you did mean renegotiation in the above statement.  I don't think that making any recommendation to this effect will have any material impact on the sorts of bugs we've seen with renegotiation.  You can *say* that people should do this or that because it's good practice, but I think that that is just wishful thinking.

---

From: Tapio Sokura <[email-masked]>
Date: Fri, 27 Jun 2014 01:18:10 +0300

> 3.  Not in favor of removing renegotiation 

I would choose 1 or 2. I wonder how many real-life usage scenarios
actually move enough data and/or over long enough time to need rekeying
for real cryptographic reasons. In case there are some, I'm including 2
on my list.

dh_rsa and dh_dss can also be dumped in my opinion.

  Tapio

---

From: Watson Ladd <[email-masked]>
Date: Thu, 26 Jun 2014 18:23:34 -0700

> sell than TLSv1.2 and IPv6.

I think this is an excellent point: unless we are making TLS 1.3 web
only, and committing to supporting TLS 1.2 (including renegotation!)
for
a long time, we cannot ax this feature. As much as I dislike
renegotiation, it may be that we need to include it as an optional
feature if we want to replace TLS 1.2.

Conversely, if we're committed to stabilizing the security flaws in
TLS 1.2 and phasing it out, while not having everything upgrade to TLS
1.3, we can get away with eliminating  renegotation.

Sincerely,
Watson Ladd

---

From: Yoav Nir <[email-masked]>
Date: Fri, 27 Jun 2014 08:14:12 +0300

On Jun 27, 2014, at 1:18 AM, Tapio Sokura <[email-masked]> wrote:

> for real cryptographic reasons.

Depends on what you mean by “cryptographic reasons”. As we’ve seen with other messages on this list, with AES-GCM you’re fine to use the same key for 2^64 or 2^48 records or packets. Either is a huge amount, and I don’t think we have scenarios that need that much data in a single session.

There is another reason, that I don’t know if you’d call “cryptographic” to rekey. It’s similar to forward secrecy. If you have a session that runs for days on the same key, an attacker can record the session, then use some out of band means (like a warrant) to force one side to hand over the key. Deleting the crypto key every hour or so helps here.

Yoav

---

From: James Cloos <[email-masked]>
Date: Fri, 27 Jun 2014 10:13:23 -0400

>>>>> "CM" == Colm MacCárthaigh <[email-masked]> writes:

CM> This too seems like a strawman; SSH does not use TLS, and
CM> telnet-over-tls is not common. The requirements of securing
CM> interactive logins differ enough from TLSs features that those
CM> applications have found other solutions entirely.

So what about something like an sctp connection between switches
actively carrying hundreds or thousands of concurrent calls, each
on a sub-socket.  Even with the media following a different path,
the signaling has to remain up.

I presume xmpp/tls/tcp/ip works similarly.

That is a lot of state to have to redo.

If tls1.3 drops rekeying established sockets, then one reasonably can
predict that its adoption will be limited enough that any security
benefits it has over 1.2 will be, mostly, for naught.

Whether rekeying requires renegotiation should be the question.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Brian Hamon <[email-masked]>
Date: Fri, 27 Jun 2014 16:10:49 +0000

Unless someone makes a case otherwise, I think that the answer to my question is that client authentication (assuming Martin's proposal is accepted) is either required from initial ServerHello or unavailable?

This may be where the WG wants to take TLSv1.3, and from an OSI layering perspective might be the best result. After all, if the application is making the decision on whether to require client authentication, then client authentication is best addressed at the application layer. If so, then perhaps this committee should eliminate client authentication completely from TLS.

> My main concern is that if your proposal is accepted, what is the solution for a server that must examine 
> some ApplicationData in order to determine if client authentication is required?

---

From: Martin Thomson <[email-masked]>
Date: Fri, 27 Jun 2014 09:25:53 -0700

> Unless someone makes a case otherwise, I think that the answer to my question is that client authentication (assuming Martin's proposal is accepted) is either required from initial ServerHello or u…

There are other options:

1. TLS 1.3 could allow clients to authenticate unilaterally (i.e., not
require the CertificateRequest message to be sent before sending a
client cert, or mandating that servers provide a CertificateRequest
always).

2. Authentication might be provided with a separate type of control
message.  This has been discussed.

And any combination of the above, depending on what we think best fits
the complexity/functionality trade-off.

Personally, I like the idea of doing option 1 here.  With
confidentiality protection for handshake messages, it could make
client authentication considerably more accessible than it was in
previous TLS versions.

> [...] perhaps this committee should eliminate client authentication completely from TLS.

I haven't seen much interest in doing that.  My proposal still relies
on TLS providing a binding to client credentials.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Jun 2014 09:28:45 -0700

On Fri, Jun 27, 2014 at 9:25 AM, Martin Thomson <[email-masked]>
wrote:

> > Unless someone makes a case otherwise, I think that the answer to my
> question is that client authentication (assuming Martin's proposal is
> accepted) is either required from initial ServerHello or unavailable?
>
>
> There are other options:
>

I would oppose that. There are plenty of situations where mutual
authentication
is needed in TLS.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Fri, 27 Jun 2014 09:30:44 -0700

> Whether rekeying requires renegotiation should be the question.

We're all running the same sort of questions over.

I've been looking at TCP crypt and their informal requirements
document says this:

           [...]  Use of a single key over a long connection is a
           known security problem, so it would be preferable to either
           limit the length of a connection or require in-band keying
           support.

           Unfortunately, not all applications are easy to restart.
           BGP, for which this option is intended, is being augmented
           for graceful restart [RFC4724] [RFC4781], but this extension
           is under recent scrutiny.  TCP itself has no limit on the
           length of a connection, and it would be preferable to avoid
           modifying this semantic.

I think that this last sentence answered the rekeying question for me.
TLS is considered widely as TCP+security (as much as that abstraction
occasionally leaks, c.f., packet length).

---

From: Brian Smith <[email-masked]>
Date: Fri, 27 Jun 2014 10:05:22 -0700

>            limit the length of a connection or require in-band keying

Citation needed. In particular, what is the definition of "long" here, and
what is the security problem, precisely? Usually a cipher's documentation
will specify what it means to use a key for too long, and nobody here is
proposing to use a key longer than a cipher's specification allows.

> occasionally leaks, c.f., packet length).

Theoretical limitations don't matter as long as the practical limitations
are reasonable. When the misinformation about AES-GCM being limited to 2^32
records was being considered, it did seem like the practical limitation was
bordering on being unreasonable. But, now it seems like the practical
limitation is >=2^48 records for the cipher suites that will be retained in
TLS 1.3 anyway, and I don't see 2^48 records as being such a significant
limitation that we must make the protocol significantly more complex to get
around it.

My current preference is to remove renegotiation and rekeying altogether,
option 1.

That said, I think the "forward secrecy" goal of your rekeying proposal
potentially has merit as a justification for the feature, but it needs to
be fleshed out before anybody can understand it and judge it. I think it is
worthwhile to write out the requirements for that feature, decide whether
the feature is justified for inclusion in TLS 1.3 (it seems like scope
creep to me), and then explore whether a restricted or otherwise modified
form of the current renegotiation mechanism can be used for that feature.
Reusing a restricted form of the current renegotiation mechanism would
reduce complexity for existing implementations that already support
renegotiation, whereas adding a new rekeying mechanism seems guaranteed to
add significant complexity which would make it a breeding ground for
implementation mistakes. However, it isn't clear (a) whether we need any
rekeying in TLS 1.3, or (b) whether restricted renegotiation or a new
rekeying mechanism is better.

Cheers,
Brian

---

From: Brian Hamon <[email-masked]>
Date: Fri, 27 Jun 2014 17:09:34 +0000

From: Eric Rescorla [mailto:[email-masked]] 
Sent: Friday, June 27, 2014 9:29 AM
To: Martin Thomson
Cc: Brian Hamon; <[email-masked]>
Subject: Re: [TLS] Call for Consensus on removal of renegotiation

On Fri, Jun 27, 2014 at 9:29 AM, Eric Rescorla <[email-masked]> wrote:
>On Fri, Jun 27, 2014 at 9:25 AM, Martin Thomson <[email-masked]> wrote:

Interesting and elegant proposal... Assuming we don't create headaches for implementers or 
opportunities for DoS, I would favor this also.

> I would oppose that. There are plenty of situations where mutual authentication
is needed in TLS.

I engaged in reductio ad absurdum there, because without either of these additional mechanisms,
client authentication is impossible (in some very specific use cases over which apparently I uniquely 
obsess). 

We must have server authentication at the transport layer, in order to securely negotiate the master 
secret. TLS strives for symmetry, allowing the same implementation to be used in clients and servers. 
Therefore client authentication must be in TLS, even though authentication in the transport layer
is a violation of the OSI model. Anything that moves the Internet away from password-based
authentication is a win.

Making "client authentication considerably more accessible than it was in
previous TLS versions" should be a high priority goal for TLSv1.3.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 27 Jun 2014 11:07:23 -0700

On 27 June 2014 10:05, Brian Smith <[email-masked]> wrote:
> potentially has merit as a justification for the feature, but it needs to be
> fleshed out before anybody can understand it and judge it. I think it is
> the feature is justified for inclusion in TLS 1.3

That's a reasonable ask.  I'm happy to expand on that elsewhere, but
I'll try to keep the focus on resolving this point first.

---

From: Andy Lutomirski <[email-masked]>
Date: Fri, 27 Jun 2014 12:03:42 -0700

> feature if we want to replace TLS 1.2.

Are there any known non-HTTP users of renegotiation for client auth that
wouldn't work out of the box with unsolicited client auth during the
handshake?

The only compelling objection to removing renegotiation for client auth
that I heard was that it would be unfortunate for TLS 1.3 to only be
usable with an upgraded HTTP stack.  That's not a show-stopper, but it's
annoying.

Allowing delayed client authentication without a new handshake would
solve this problem, is cryptographically very simple*, but integrating
it into the protocol might be quite complicated.

* It would preclude using tricks like triple DH directly, though.

--Andy

---

From: Steve Checkoway <[email-masked]>
Date: Sat, 28 Jun 2014 15:58:10 -0400

> 3.  Not in favor of removing renegotiation

I prefer 2.

-- 
Steve Checkoway

---

From: Alyssa Rowan <[email-masked]>
Date: Sun, 29 Jun 2014 15:35:12 +0100

> [Joe] to simplify:

I support 2: In favor of removing renegotiation with the addition of
rekey.

TLS <=1.2 renegotiation is hairy - but though it's not the most
commonly-deployed profile right now, rekeying is needed (for large
traffic volumes/long-lived connections, and potentially for
'ratcheting' the forward-security of connections?), as is
client-certificate authentication.

Happily, there are better ways of doing both of these than the current
renegotiation flow - so we can remove renegotiation as it stands, and
address these use-cases with better methods.

If we remove it otherwise, some people who need TLS won't be able to
use TLS 1.3, and I suspect that will be a barrier to adoption we don't
want.

- -- 
/akr