Subject: [TLS] TLS 1.3 process

From: Sean Turner <[email-masked]>
Date: Thu, 27 Mar 2014 17:48:47 -0400

All,

The TLS WG charter is pretty clear that the intention isn't to design
a completely new protocol but rather to revise TLS, and specifically
to "place a priority in minimizing gratuitous changes to TLS." This
is not to say that we can't consider new cryptographic handshake flows
-- TLS has always been open to that -- but completely replacing TLS
with a new protocol is out of scope for this WG.

With this in mind and regard to the bigger question about the
process, here's how the chairs intend to proceed:

1. Start with the existing TLS document. As usual in IETF, this
   doesn't mean that any particular piece of the document cannot
   be changed if the WG wants to, but it's where we will start;
   it also makes it a lot easier to get through the process
   since the IESG, directorates, and WGs that depend on TLS 
   can see what changed.
2. If possible, remove the pieces we agree we don't need (hence the
   recent consensus calls).
3. Settle on the high-level handshake flows (charter items #1 and #2)
   in light of #2.
4. Reevaluate the handshake PDUs (charter item #4)
5. Update record protection mechanisms in the record layer
   (charter items #3 and #5)
6. Iterate on the document until complete. Key to this process is
   getting input from academic cryptographers, which is why we
   are prioritizing the handshake flows, because they are probably
   the piece that needs the most analysis.
7. Publish.

With that said, the reason for the present consensus calls should be
clear, as they are intended to either remove pieces (#2) or resolve
requirements for the handshake (#3).

To sum up: We have a set of requirements, from the charter and
from the consensus calls we're having now.  Our chartered goal is
to meet those requirements with the minimum set of changes to TLS. 

TLS co-chairs

j & e & s

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 27 Mar 2014 15:45:56 -0700

> with a new protocol is out of scope for this WG.

Hi Sean,

Thanks for creating this discussion.

The distinction between a "new protocol" (forbidden!) and
re-evaluating / updating both the handshake and record layer is not
super clear to me.

For example: Eric's draft redesigns the TLS handshake around the new
concept of "semi-static public keys".  That gave me the impression
we're willing to consider radical changes!  Is that not the case?

I also didn't expect such a strict interpretation of the charter, and
such a rigid process.  Your email in January gave a different
impression:

"""
Rene,

A couple of people have mentioned the fact that list of objectives is
incomplete or they're worried their issue not being listed means it's
out of scope.  Right now the charter includes the following to address
this (at least in my mind) "Some of the main design goals are as
follows, in no particular order:"  That list is honestly there to make
sure the IESG will be comfortable agreeing to the rechartering.  What
I hope will happen is that folks can bring their proposals, they get
evaluated, and the WG will use its better judgement about what makes
sense to get adopted.
"""
http://www.ietf.org/mail-archive/web/tls/current/msg11257.html

That email made it seem like we should not worry too much about the
charter, we'd have time for "folks to bring their proposals" later.

I would have asked for more clarity on the charter - and the
"minimizing gratuitous changes" phrase - if not for that.

Anyways, maybe this is just me.  If everyone else understand what
scope of changes is allowed, and is happy with the step-wise process
you describe, then that's fine.  I'm happy we're discussing this.

But I would personally prefer a more open process based around
soliciting and comparing different proposals, without pre-judging in
advance what changes are "gratuitous".

Trevor

---

From: Watson Ladd <[email-masked]>
Date: Thu, 27 Mar 2014 18:56:26 -0400

>    the piece that needs the most analysis.

I don't think this will work out well for the following reasons.

Firstly, the TLS spec is a mess. Necessary extensions aren't included,
so if you want to use ECDHE, you need to go on a hunt for the proper
specification. Likewise, if you want secure renegotiation, that gets
incorporated by reference also. There isn't a clear model of what is
supposed to happen in conforming implementations. Fixing this will
require major editing. ECDHE encodings can't accommodate anything that
isn't a short Weierstrass curve over a prime or binary field, which is
causing trouble on curve25519. This sort of housekeeping isn't
interesting, or rewarding. It is necessary to avoid the "Oh, well,
this RFC you never heard off addresses the issue in the one you
thought would be the right one to look at" problem.

Secondly, the record layer issues are much worse than the handshake
issues in TLS 1.2. There are good handshakes like ECDHE_RSA and
ECDHE_ECDSA available today, with side-channel protected
implementations on all platforms. That cannot be said for the record
layer: AES-GCM only works on late Intel hardware without side
channels, even with the Käsper-Schwabe implementation. It would be
desirable for any fix for this issue to work on TLS 1.2 as well. There
are already drafts handling this, as well as work in UTA. Tying this
work to a version number bump would be ridiculous.

Thirdly, the handshake issues are much worse than the record layer
issues in TLS 1.2. We understand what the record layer is supposed to
do. We don't understand what the handshake is supposed to do: channel
bindings got broken because they made assumptions that the handshake
layer didn't in fact meet. In contrast we understand very well what
the record layer is supposed to do, and why the existing options fail.
I don't see people thinking about the interactions between 0-RTT,
existing resumption, and channel binding. It could be quite fun. We
still don't have anything concrete to critique or analyze here.

Given all this, I would say the best thing to do is focus on the
handshake while the committee does the record layer enhancements via
enhancements to TLS 1.2, and have TLS 1.3 focus on the handshake fixes
and enhancements that are required after that.

Sincerely,
Watson Ladd

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

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Mar 2014 16:06:51 -0700

> advance what changes are "gratuitous".

I'll note two things here:

1. nothing leaves the working group until there is consensus for it to
do so, no matter what process has been followed

2. nothing prevents you or anyone from making a proposal...at any time

If it turns out that major surgery or even a complete rewrite is
necessary, and there is working group consensus for either, then I
have faith that someone will make that proposal.  And that proposal, I
hope, will be judged on its merits.

So far, I haven't seen any evidence that what Sean describes is a bad
plan.  In fact, since our chairs have run this rodeo before, I have a
strong suspicion that this is a decision based on experience with
getting results.  I would like results.

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 27 Mar 2014 16:57:23 -0700

> 2. nothing prevents you or anyone from making a proposal...at any time

Sure, here's my proposal:

 * The WG chairs continue to encourage discussion of goals and design
alternatives for TLS 1.3.  However, the WG holds off from making
binding decisions regarding TLS 1.3.

 * The WG encourages interested parties to submit proposals for TLS 1.3.

 * In X months time (4-6?), the WG chooses which proposal to adopt as
the base for TLS 1.3, and works to improve it for publication.

Trevor

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 27 Mar 2014 22:13:33 -0400

Does it make sense to consider splitting tls-ng a/k/a tls-2.0 into a separate WG?

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 28 Mar 2014 10:15:27 +0100

> the base for TLS 1.3, and works to improve it for publication.

I second that.

---

From: Douglas Stebila <[email-masked]>
Date: Fri, 28 Mar 2014 12:28:40 +0000

>> the base for TLS 1.3, and works to improve it for publication.

Please leave a healthy dose of time for academic cryptographers to analyze the protocols and try to develop attacks or proofs of security.  Complex message flows / state machines, like renegotiation and resumption, are hard to model and hard to prove.  Even if renegotiation is axed, we may have TLS candidates with complex flows and states, such as a zero round trip protocol with partial forward secrecy for parts of the handshake and initial application data and then the whole connection upgraded to forward secrecy on the server reply.

Douglas

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 28 Mar 2014 10:12:30 -0400

> The TLS WG charter is pretty clear that the intention isn't to design a completely new protocol but rather to revise TLS,
> and specifically to "place a priority in minimizing gratuitous changes to TLS."

+1.

It seems to me that there are almost three viewpoints within this WG.  With the hope that I'm equally unfair to everyone, I'd summarize them like this:
	- Update to modern crypto knowledge to fix bugs, and some modern features and be done
	- Make big changes to fix serious problems
	- Start over from a clean sheet; "I don't know what it will be, but we'll call it TLS."

I put myself in the first group (except for SNI encryption, which will get a separate post :), could be convinced to support something from the second once it's written down, and am probably not qualified to evaluate anything from the third group (few people are). Interestingly, barring divine intervention, the above list is probably in order of length of time needed, as well. That would seem to indicate that there's room for all three efforts here.

	/r$

---

From: Watson Ladd <[email-masked]>
Date: Fri, 28 Mar 2014 11:01:51 -0400

> I put myself in the first group (except for SNI encryption, which will get a separate post :), could be convinced to support something from the second once it's written down, and am probably not qu…

I think the first issue should be our biggest priority: leave the
handshake largely alone, focus on fixing insecure resumption and the
record layer, removing compression, mandate secure renegotiation,
document 1/N-1 record splitting. All of this needs to be done in TLS
1.2, and there are drafts for most of it already.

Once that's done, we can turn to things like zero-round handshakes and
caching and encryption of handshakes.

As much as I like 3, I don't think it will ever happen. Maybe IoT will
be looking for something much more lightweight? There are alternatives
like MinimalLT and CurveCP, but takeup is understandably slow.

Sincerely,
Watson Ladd

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 28 Mar 2014 15:40:12 +0100

> I put myself in the first group (except for SNI encryption, which will get a separate post :), could be convinced to support something from the second once it's written down, and am probably not qu…

This is not my impression of the discussions and the meetings. Eric in
the last meetings has presented a list of changes to the protocol that
really exceeds the "Update to modern crypto knowledge to fix bugs, and
some modern features and be done", (whatever that means).

So my understanding is that there will be big changes (e.g., reducing
handshake messages, redesign of handshake to encrypt everything) to fix
serious and not serious problems (e.g., reducing the round-trips), and
the question is whether to do it:
1. within the working group (which is stated to have no crypto
expertise).
2. by using external expertise.

regards,
Nikos

---

From: Adam Langley <[email-masked]>
Date: Fri, 28 Mar 2014 11:24:56 -0400

> 1.2, and there are drafts for most of it already.

I would rather like to see a TLS 1.3 that is a tidying up of 1.2:
merging the various RFCs into one, editing and pulling in some of the
drafts that are floating around. The more significant changes could be
1.4.

Of course that all depends on someone actually doing the work and I
might be up for that too.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Mar 2014 08:34:29 -0700

On Fri, Mar 28, 2014 at 7:40 AM, Nikos Mavrogiannopoulos <[email-masked]>wrote:

> a completely new protocol but rather to revise TLS,
> > It seems to me that there are almost three viewpoints within this WG.
>  With the hope that I'm equally unfair to everyone, I'd summarize them like
> this:
> > I put myself in the first group (except for SNI encryption, which will
> get a separate post :), could be convinced to support something from the
> second once it's written down, and am probably not qualified to evaluate
> anything from the third group (few people are). Interestingly, barring
> divine intervention, the above list is probably in order of length of time
> needed, as well. That would seem to indicate that there's room for all
> three efforts here.
>
> serious and not serious problems (e.g., reducing the round-trips),

Yes, I think the changes to the handshake we have been discussing
probably would fall under #2 in Rich's taxonomy.

> and

I actually don't think think this is the question, since IETF work is
done in WGs and we would reach out (and are reaching out) for
external expertise in any case.

-Ekr

---

From: Watson Ladd <[email-masked]>
Date: Fri, 28 Mar 2014 12:35:27 -0400

On Fri, Mar 28, 2014 at 11:34 AM, Eric Rescorla <[email-masked]> wrote:
>> > needed, as well. That would seem to indicate that there's room for all three
>> > efforts here.
>>

But what Rich neglected to point out is that you have to do #1 anyway.
The bugs in TLS 1.2 and older versions need fixing. If you end up
tying that fix together with a bunch of bigger changes, they won't get
fixed because people will (incorrectly) see this as a new version
rather than a bundle of necessary fixes with some new features.

There is no reason to bundle the record layer/handshake fixes and
handshake enhancements together.

> external expertise in any case.

Kenneth Patterson and Peter Gutmann are in the WG.

Sincerely,
Watson Ladd

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 28 Mar 2014 09:52:24 -0700

>> >       - Start over from a clean sheet; "I don't know what it will be,
...
> probably would fall under #2 in Rich's taxonomy.

Agreed with Nikos and Eric that the WG (and charter) seemed willing to
consider major changes, as evidenced by the interest in Eric's "new
flows" draft.

If anything, I'm not sure the difference between Rich's #2 and #3
really exists - if we're willing to replace the existing TLS initial
and resumption flows with a flexible composition of exchanges based
around semi-static public keys, zero-RTT pre-emptive encryption, and
anti-replay tokens (Eric's draft) - and revisit the crypto - then
we're designing a new protocol, whether we admit it or not.

> external expertise in any case.

Don't fully agree with Nikos.  For (1), this WG *does* have
participation from many cryptographers.  For (2), it's true anyone can
participate.

But Nikos has a point - there are differences in how processes
encourage or discourage participation.

I think creating a complex protocol by trying to reach consensus on a
hundred different points individually will result in a huge volume of
complicated, hard-to-follow discussions, which will need to be sorted
out at f2f meetings with substantial wrangling and steering from the
chairs.

So the only people able to fully participate will be those willing to
invest hours a day deciphering mailing list threads and trying to
"win" discussions, and spend the time and money to attend IETF
meetings where the big decisions will be made.

In contrast, a process based around alternative proposals makes it
much easier to participate by either submitting a proposal or
reviewing others.  And the range of things being considered becomes
much more legible, since once can review a few leading proposals
instead of trying to reverse-engineer debates embedded in thousands of
mailing list posts.

Trevor

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Mar 2014 13:28:40 -0700

> Kenneth Patterson and Peter Gutmann are in the WG.

My bad! I certainly didn't mean to suggest that we didn't have anyone in the
WG with cryptographic expertise. We also have Uri Blumenthal, Hugo Krawczyk
(from time to time), David McGrew, Marsh Ray, Hovav Shacham, and a bunch of
other people I apologize to in advance for not mentioning.

-Ekr

---

From: Bill Frantz <[email-masked]>
Date: Sat, 29 Mar 2014 15:49:16 -0700

One place where IMHO, the process is lacking is in having a set 
use cases to test our proposals against. With use cases, we can 
more easily avoid the tendency to Baroque and Rococo interfaces 
by asking how a particular feature supports one of our use 
cases. The proposer can either answer how it supports an 
existing use case, or propose a new use case which does support. 
Than new use case can be either added or rejected by the group.

It seems to me obvious that two use cases we must support for 
TLS are:

   HTTP

   Mail (POP, SMTP, IMAP)

Are there any others?

I don't know much about the real-world uses of DTLS, so others 
will have to propose DTLS use cases.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        | Re: Computer reliability, performance, and security:
408-356-8506       | The guy who *is* wearing a parachute is 
*not* the
www.pwpconsult.com | first to reach the ground.  - Terence Kelly

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 29 Mar 2014 18:57:28 -0700 (PDT)

Hi Bill,

> It seems to me obvious that two use cases we must support for

  See /etc/services. Basically, everything that uses the transport layer
should be able to use transport layer security if it wants to.

  I think we should avoid to the fullest extent possible having application
layer use cases to guide TLS 1.3 development. The less the application
layer intrudes onto TLS the better. (I think NPN/ALPN is architecturally
a bad idea).

  regards,

  Dan.

---

From: Bill Frantz <[email-masked]>
Date: Sat, 29 Mar 2014 20:05:28 -0700

>should be able to use transport layer security if it wants to.

Transport layer doesn't have key agreement, end point 
authentication, reconnect etc. etc. etc. We need use cases to 
define what is needed in these areas.

Watson is correctly concerned that we get the transport 
encryption to work correctly. Transport layer encryption might 
include bi-directional data transport, end point synchronization 
etc., but if there are no use cases, it is hard to justify 
spending a lot of effort to support them.

We need use cases if only to be sure we are supporting what 
needs to be supported.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Since the IBM Selectric, keyboards have gotten
408-356-8506       | steadily worse. Now we have touchscreen keyboards.
www.pwpconsult.com | Can we make something even worse?

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 30 Mar 2014 09:23:15 -0700 (PDT)

On Sat, March 29, 2014 8:05 pm, Bill Frantz wrote:
> authentication, reconnect etc. etc. etc.

  That's what Transport Layer _Security_ (i.e. TLS) is for.

>                                                              We need use
cases to
> define what is needed in these areas.

  I disagree.

> spending a lot of effort to support them.

  Well bully for Watson. But everyone in the WG is concerned
about getting encryption to work correctly. We're also all
concerned about getting authentication to work correctly.
And about getting authenticated encryption to work correctly.

  I fail to see how documenting use cases will help us get
encryption to work correctly, unless you think there are some
use cases for which correctly working encryption is not a
requirement. If that's the case then then have no impact on
TLS 1.3.

> We need use cases if only to be sure we are supporting what

  Documenting use cases is an unnecessary distraction from
doing actual work. You'll note that our charter does not say
"enumerate applications that want to use TLS".

  Dan.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 30 Mar 2014 12:56:34 -0400

One use (sic) of use-cases is that they are helpful to determine what's in-scope and what's out of scope.  For example, DNS is typically over UDP and doesn't care about replay or out of order. TLS-layer compression has security issues, and arguably application-level compression can be more effective by leveraging semantics (e.g., HTTP2 headers).  Both of those cases impact encryption.

I share the concern about not being distracted, but nowhere near as strongly as Dan.  And we're certainly not all concerned about getting authentication working correctly; it depends on what the definition of correctly is, I suppose.

	/r$

---

From: Bill Frantz <[email-masked]>
Date: Sun, 30 Mar 2014 17:33:28 -0700

On 3/30/14 at 9:23 AM, [email-masked] (Dan Harkins) wrote:

>... everyone in the WG is concerned

SSL/TLS was built with one use case in mind -- HTTP. As a 
result, TLS authentication is optimized for the stranger meets 
stranger case where a user wants a secure connection to a web 
site knowing only the domain name. This HTTP oriented 
authentication is poorly adapted to the requirements of 
encrypted communication with email servers where connections 
between the email user and the server are repeated many times a 
day, day after day. What other application areas are also poorly 
served? Without use cases we have no idea.

The problem isn't that we all don't want encryption, 
authentication, traffic analysis resistance etc. to work 
correctly. The problem is that we don't know what correct 
operation is. And we can't know unless we have an idea of what 
at least some of the uses are.

>"enumerate applications that want to use TLS".

We don't have to enumerate all the uses. What we have to do is 
have enough examples of different uses to let us have a chance 
that we are actually serving a wide range of them.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | "The only thing we have to   | Periwinkle
(408)356-8506      | fear is fear itself." - FDR  | 16345 
Englewood Ave
www.pwpconsult.com | Inaugural address, 3/4/1933  | Los Gatos, 
CA 95032