Subject: [TLS] Bakeoffs

From: Cullen Jennings <[email-masked]>
Date: Tue, 15 Apr 2014 09:39:17 -0700

Not that this is relevant, since the WG has already been chartered
and my reading of the charter is that we are to revise TLS,
not to do a contest for something entirely new. However,
long-time IETF experience with bake-offs is generally really
bad.

The IETF process is good at making decisions where one looks at a
change, then decides if that changes will work or not from a technical
point of view and how to tweak it so it will work in most cases. The
IETF process is crappy at choosing between two proposals where both
would work and a bunch of people would prefer A and a bunch of others
would prefer B but everyone agrees both A and B both basically
work. You can see the chairs of rtcweb flailing to try and find any
way to resolve the H.264 vs. VP8 questions in that WG. I‘m one of the
flailing co-chairs so I have spend some time looking at this.

When we look back at the history of bake-offs that I have been
involved with at IETF, the outcomes were not great. (BTW, that
bake-off is TM and you aren’t allowed to use it at IETF). Midcom took
so long everyone that was building products gave up and used something
else. LOST, a protocol primarily driven to help E911 work on phones,
used a bake-off and I’m unaware of any jurisdiction that has deployed
LOST outside of trials. I’m sure there are multiple theories why but
one of them would be people just did other things having watched how
much the bake-off process polarized the community. People were so
upset at outcomes that they just did proprietary solutions. The P2PSIP
community spent s long arguing about to converge that eventually the
authors more than the WG decide how to merge the proposal down to one
that had enough critical mass to get consensus in the WG. That was a
painful and far from ideal way to move forward. The selection of who
to encrypt RTP took years and in the end managed to get to strong
consensus but even with that the factions that did not win have
continually caused enough uncertainty in the market place to
substantial reduce deployments.

The basic issue is bake-offs take too long in the IETF process and
don’t have a deterministic way to complete in finite time. What
happens is along the lines of you get 5 proposals - along with much
hype about each of them. You then ask the WG to choose, the great
surprise happens that the WG can not choose. So you decide to write
use cases to drive requirements and then to analyze each of the 5 to
see what happens. In the meantime the 5 merge to 3 and the all 3
evolve so they are functionally equivalent. Note that the merging and
evolution, by definition, involves a fair amount of bloat and
complexity added to at least 2 out of the 3 to ensure they are equally
bloated. By the time the analysis is finished, all the proposal meet
all the requirements and 4 years have gone past. Now the really sad
thing happens - the WG still can’t decide. Some times what happens
next is eventually enough people decide the outcome is so irrelevant
in the real world that they stop coming to the WG and after time you
you have a small enough group to make a choice. So basically you can’t
make a decision until after the decision is irrelevant to deployments.

I think the IETF needs some experiments to find a better way to make
decisions like this, but I don't think TLS is the place for that.

Cisco does quite a bit of TLS in our products and from that
perspective, what I'd like to see is a TLS 1.3 that finishes
quickly. I don't believe that a competition/bakeoff is that way to do
that. Given that we already have a protocol widely deployed, we
should focusing on improving that, not holding a contest for
something totally new.

---

From: Russ Housley <[email-masked]>
Date: Tue, 15 Apr 2014 12:55:03 -0400

Cullen:

I would also like to see a TLS 1.3 process that goes quickly, focusing on:
 - choosing mandatory to implement algorithms that have a lot of community confidence,
 - throwing out little-used options, and
 - making incremental improvements.

Bakeoffs are not good tools for making decisions.  By contrast, I have seen that getting a bunch of implementers in a room and working out interoperability issues does lead to better specifications.  The problems that are encountered often identify the rough spots in the text.  Also, these sessions provide a lot of useful information to the implementers themselves.

Russ

---

From: Watson Ladd <[email-masked]>
Date: Tue, 15 Apr 2014 10:00:00 -0700

> flailing co-chairs so I have spend some time looking at this.

TLS right now doesn't work. We also have a problem with making
implementations because of the complexity, which means OpenSSL is in the
TCB.

Bakeoffs are much easier for competent people to look at each option
because they are static. They reward coherent, simple designs.

> decisions like this, but I don't think TLS is the place for that.

TLS has usecase: authenticate Alice and Bob to each other, letting one side
be anymous, via X509. That's it.

> should focusing on improving that, not holding a contest for

The quickest finishing process is no process: you don't do anything. What
about the substance?
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Yoav Nir <[email-masked]>
Date: Tue, 15 Apr 2014 22:49:35 +0300

Hi Cullen

You have listed several cases of failed competitions, and IPsecME can provide two others. OTOH we have the shining example of httpbis, although I think the two things that made that effort a success was that (a) the proposals were not all that different from each other, and (b) everyone in the room and on the mailing list preferred getting to work on some solution rather than debating endlessly. That last one was missing from many of the other efforts.

But anyway, the only proposal we have for TLS 1.3 is the diagrams in Eric’s draft. A lot of people say they want a competition. But this is the IETF. Anyone can submit a draft if they want to. If any of these people submitted a 5-page draft outlining what they think the next TLS should look like, we would discuss and compare the two options regardless of whether the chairs and ADs want to have a competition or not. So far, nobody’s come forward. So we’re all talking about some hypothetical alternate TLS protocol. 

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Apr 2014 13:11:17 -0700

> You have listed several cases of failed competitions, and IPsecME can provide two others. OTOH we have the shining example of httpbis, although I think the two things that made that effort a succes…

I don't think that HTTP/2 is a good example of a bake-off, because it
didn't really work out that way.  To put this as inelegantly as I can,
HTTP/2 succeeded (or seems likely to) because it does exactly what the
IETF does best: take something that works and ram it through the
process with minimal changes.  What might, to an outsider, have looked
like a bake-off back when the effort started, wasn't really a
competition between two or more equally well-formed proposals.  There
was SPDY, which we are using, then there were what amounted to
statements of principle from a couple of other groups.  What the
process did was allow those principles to be expressed, and to have
those tested and integrated as consensus permitted.

I think that we've strong support for the idea that HTTP/2 is strictly
better than SPDY as a result, but that doesn't mean that everyone is
getting what they want either; what was clear from this is that all
those involved were able to put aside viewpoints where they were
outside consensus.  A bake-off can reduce the chance of this happening
by forcing different parties to become strongly aligned with certain
ideas.

I generally support Cullen's thesis here.  There are few enough people
willing to invest the time needed to get the work done in the first
place.  Forcing the group to divide their efforts and then providing
incentives against working together doesn't seem like it's an
experiment worth re-running.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 15 Apr 2014 16:28:44 -0400

>TLS doesn’t work.

Well, that’s a bit of an exaggeration.  Kinda like when I would say to the kids “I’ve told you a million times not to…”

I’m opposed to a bakeoff.  It doesn’t seem like a “standard” bakeoff, in which we bring existing implementations of mostly-done specs.  Others have commented on the history. This seems more like a spec bake-off, which isn’t really a bake-off but more of a competition. How does that get better code out there?  Rough consensus and running code is the phrase, and I don’t see a competition to create TLS2 as a way to get a “better” TLS in the hands of consumers during 2014.

And, if we got rid of the SNI encryption :) the number of changes being considered is pretty small in both number and scope.

                /r$

--
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 15 Apr 2014 17:42:02 -0700

On Tue, Apr 15, 2014 at 12:49 PM, Yoav Nir <[email-masked]> wrote:
> You have listed several cases of failed competitions, and IPsecME can provide two others.

Hi Cullen and Yoav - most of your examples seem like evidence that:
 (a) performing major protocol design in the IETF is very hard, and often fails
 (b) WGs sometimes reach irreconciliable differences

Having multiple competing proposals seems like a symptom of these
problems much more than a cause.

Trevor

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 15 Apr 2014 17:46:17 -0700

On Tue, Apr 15, 2014 at 1:28 PM, Salz, Rich <[email-masked]> wrote:
>
> I'm opposed to a bakeoff.  It doesn't seem like a "standard" bakeoff, in
> which we bring existing implementations of mostly-done specs.  Others have
> commented on the history. This seems more like a spec bake-off, which isn't
> really a bake-off but more of a competition. How does that get better code
> out there?  Rough consensus and running code is the phrase, and I don't see
> a competition to create TLS2 as a way to get a "better" TLS in the hands of
> consumers during 2014.
>
> And, if we got rid of the SNI encryption :) the number of changes being
> considered is pretty small in both number and scope.

So Cullen, Russ, Martin, and Rich all expressed interest in a TLS 1.3
that completes quickly and with small changes to TLS 1.2.

Maybe this argues for Adam Langley's earlier suggestion (also endorsed
by a few others) that we focus on a TLS 1.3 that is a "tidying up" of
1.2, and push the larger goals (e.g. redesigning handshake for
lower-latency or more encryption) to a TLS 2.0?

Trevor

[1] http://www.ietf.org/mail-archive/web/tls/current/msg11691.html

---

From: Watson Ladd <[email-masked]>
Date: Tue, 15 Apr 2014 18:19:06 -0700

> But anyway, the only proposal we have for TLS 1.3 is the diagrams in Eric’s draft. A lot of people say they want a competition. But this is the IETF. Anyone can submit a draft if they want to. If a…

AGL submitted at one-sentence description: "TLS 1.2 cleaned up with
necessary extensions". Enumerate the RFCs that describe what chrome
does, and you have running code as well.

Peter Gutmann "Take a key exchange, serialize the messages, be done with it".

As an application of this principle, I suggest the following: Pick a
group and hash function and AEAD scheme
A->B: ver_cur, ver_high_a, g^a, g^x, {optional sig g^a and cert a}
B->A: ver_cur, ver_high_b, g^b, g^y, sig g^b and cert a

Abort if ver_cur is not min{ver_high_a, ver_high_b}. This provides
extensibility as cryptanalysis proceeds. Compute a key as H(message 1
|| message 2|| g^{xy} || g^{ay} || g^{bx}). Then use the AEAD scheme
with A taking nonces ending in 1 and B with nonces ending in 0. use
the associated data to indicate message ending.

Dan Brown suggested the above with HMQV, which Hugo Kraczyk
recommends. (But sadly HMQV is patented by IBM) Any of these could be
turned into a 5 page ID completely describing the desired effect. But
this isn't the question motivating the desire for a competition.

Fundamentally the question is this: Why will Eric Rescorla do
correctly this time what he failed to do correctly twice before? When
did the same leadership that permitted the phrase "but this timing
difference is not believed to be exploitable" to appear in a standards
document suddenly develop the ability and the will to ensure secure
protocols are actually secure? Oh, and RC4 was broken in 2001 by the
current head of the CFRG. The desire from a competition stems from
wanting authors who don't have this history of failure to be the ones
who write the next TLS.

Behind all of the debate over the TLS process is a theological
dispute: Calvinism vs. Catholicism. On the Calvinist side are those
who believe that man's efforts are inherently flawed and worthless,
that one's best intentions and conduct can be utterly disregarded by
the universe, that will determine if your protocol is secure or not.
Nothing can change what is or is not secure: one can only hope,
through the science of mathematics, that one has eliminated every
known flaw and reduced the problem to one that has never been
attacked. When Claus Diem publishes a paper, he has revealed what has
always existed, and merely escaped our notice.

On the Catholic side are those who believe that the universe smiles
upon cryptographers, that there is a redemptive power that can make a
flawed protocol whole again, that the flaws in protocols are an
inherent fact of human activity that can be fixed by simply redoing it
as the last one was, and hoping for a different outcome. One should
not be overly concerned by weaknesses or the need for analysis: we
simply have never been exploited this way, and so have ample time to
change should it be necessary. Minor flaws are after all minor, and
all will be forgiven.

Sadly the lives and property lost in this holy war are not those of
zealots, but of ordinary users whose simple demand: "ensure that my
communications are not intercepted" has gone unmet. What should be a
sine qua non of this group appears only as an afterthought to a single
point  "The aim is also to maintain current security features."

One can only hope for a mass baptism in Denver.

Sincerely,
Watson Ladd

-- 
"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: Tue, 15 Apr 2014 22:32:14 -0700

> that completes quickly and with small changes to TLS 1.2.

That's a not quite accurate reinterpretation of my statements.

My position is that TLS 1.3 should meet its chartered goals as
expediently as possible.  Depending on the answers to certain
questions (like the SNI question), that might involve small changes to
1.2 or it might be big.  Arguably, completely changing the record
layer as we've essentially agreed is a big change, so we're already
there.  Mostly, I don't care about the size of the changes, but more
that they are all justified and justifiable.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Apr 2014 08:29:24 +0300

> (b) WGs sometimes reach irreconciliable differences

The normal process is a 2-hour meeting three times a year, plus long debates on the mailing list. This lends itself to someone (or a small group) coming up with a design, and then lots of people analyzing, criticizing, and suggesting changes. This works OK if the design is acceptable to almost everybody and if the editors have the energy and attention to keep the thing going. That works well for HTTP/2 because we have an energized and responsive team of authors, and the changes being suggested are not that profound anymore. If the authors have less time and energy and are less responsive, you get HPKP.

With more profound differences, making decisions over email is pretty hard. Face-2-face meetings may help, as TLS is going to have next month, in that there are many more hours for discussion. 

> problems much more than a cause.

Or at least an unwillingness or inability for the designers to reach a common agreement. If there are multiple competing proposals, and the authors won’t choose or combine, it is folly to expect a mailing list to make that decision or combination for them.

It is also instructive that when NIST has an algorithm competition, it takes them six years. The IETF doesn’t have that kind of attention span. If TLS 1.3 gets published in 2020, we will consider this a failure regardless of how great it is.

Yoav

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 15 Apr 2014 22:37:51 -0700

> that completes quickly and with small changes to TLS 1.2.

I thinking I was suggesting that this WG should incrementally evolve TLS and if someone wants to make a clean slate design that is more of a revolution than an evolution, they are welcome to do that by forming some other WG.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 15 Apr 2014 22:37:57 -0700

On Apr 15, 2014, at 10:00 AM, Watson Ladd <[email-masked]> wrote:

> TLS right now doesn't work.

Wow - we have some different points of view that I doubt I will ever really agree on similar solutions. I view TLS as probably the most successful security protocol ever and incredibly important. It is what works today for a huge number of deployed products, services and users. You are wrong that bake-offs lead to simple design but our points of views are so different I am not really interested in discussing that. 

I suspect the folks that want to design something new should just grab an email list that is not the TLS email list and go design something new and propose it to the IETF. The charter of TLS does *not* say that other WG can’t go and do a different protocols that solve a similar set of problem.

---

From: Paul Lambert <[email-masked]>
Date: Tue, 15 Apr 2014 23:14:06 -0700

>> (b) WGs sometimes reach irreconciliable differences

Having worked in many different forums creating protocols Š I do agree
that the IETF process is often dysfunctional.  However, I do not see why
we consider the supposed process on this list as a limitation.  A good
design is never by a committee or mailing list, but instead by a small
design team that works closely together to create a quality specification.
 Creating a specification should not be by the random walk of the full
mailing list.

>
>The normal process is a 2-hour meeting three times a year, plus long
>debates on the mailing list. This lends itself to someone (or a small
>group) coming up with a design, and then lots of people analyzing,
>criticizing, and suggesting changes. This works OK if the design is
>acceptable to almost everybody and if the editors have the energy and
>attention to keep the thing going. That works well for HTTP/2 because we
>have an energized and responsive team of authors, and the changes being
>suggested are not that profound anymore. If the authors have less time
>and energy and are less responsive, you get HPKP.

>
>With more profound differences, making decisions over email is pretty
>hard. Face-2-face meetings may help, as TLS is going to have next month,
>in that there are many more hours for discussion.
>
>Or at least an unwillingness or inability for the designers to reach a
>common agreement. If there are multiple competing proposals, and the
>authors won¹t choose or combine, it is folly to expect a mailing list to
>make that decision or combination for them.

A group document produced by an editor is not the same as a contribution
from an ³author² (e.g ugly history of ISAKMP versus IKE).  Clarity of
goals and guidelines for cooperation of bake-off participants is
essential.  Much of the problem in the IETF is vanity ownership - getting
your name on the RFC versus having a quality group document.

>
>It is also instructive that when NIST has an algorithm competition, it
>takes them six years. The IETF doesn¹t have that kind of attention span.
>If TLS 1.3 gets published in 2020, we will consider this a failure
>regardless of how great it is.

NIST has no motivation or charter to move rapidly to deliver stronger
cryptographic algorithms to industry.

The ³bake-offs² I¹m exposed to in other standards groups are completed in
less than 6 months.  It helps to start with a clear common set of
requirements.  

Paul

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Wed, 16 Apr 2014 09:30:52 +0300

> On 16.4.2014, at 4.19, Watson Ladd <[email-masked]> wrote:
> 

I don't think these personal attacks really lead anywhere, it might be better to tone it down. I'm saying this because I've criticised this WG as well, but from my point of view the WG works really well now and everyone takes part in the discussion equally. There's been a huge improvement already.

> wanting authors who don't have this history of failure to be the ones

I like the idea of a TLS-like protocol designed from scratch. However, as has already been said, you don't need a competition for that. Anyone can send their proposal for TLS 2.0 today if they wish. I'd be interested to see some, but so far there has been no proposals.

> communications are not intercepted" has gone unmet.

As I see it, most people on this list are ordinary users with that simple demand. I simply don't see this holy war you speak of, and I hope it's not just me who doesn't.

> One can only hope for a mass baptism in Denver.

Personally, I would keep baptism and security protocols quite far from each other, even on a metaphorical level.

Juho

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 16 Apr 2014 09:55:43 +0200

On Wed, 2014-04-16 at 09:30 +0300, Juho Vähä-Herttua wrote:

> > current head of the CFRG. The desire from a competition stems from >
> wanting authors who don't have this history of failure to be the ones >
> who write the next TLS. I like the idea of a TLS-like protocol designed
> from scratch. However, as has already been said, you don't need a
> competition for that. Anyone can send their proposal for TLS 2.0 today
> if they wish. I'd be interested to see some, but so far there has been
> no proposals.

And there will be none unless there is call for proposals. Do you really
expect any university or industry group to spend significant time and
money to prepare a proposal for a TLS update, that will be submitted
"just in case someone may check it?". Especially when the chairs have
openly opposed any such approach.

This is a significant investment, that would require e.g., universities
to justify to their funding agencies the reasons of their spending. Very
few people will accept reasoning like "we spent a year designing a TLS
update just in case".

Comments like that, that anyone can submit a TLS 2.0 protocol design are
really misleading.

regards,
Nikos

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Wed, 16 Apr 2014 13:09:03 +0300

> On 16.4.2014, at 10.55, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> 

I understand the funding is a problem. Heck, I would probably start working on it myself if I had enough funding and a good team ready to go. However, I believe TLS originally succeeded not because it was the best design, but because it was done, worked and most importantly was the only reasonable candidate for its use case that could be improved together.

All a competition would do is to result in a several implementations working differently. And because each of the teams have gotten significant investments from their backers, they would have a strong agenda to push it through one way or another, and this is where it might get ugly. Because, as you just said yourself, no one wants to fund an expensive project that is just thrown away.

Wouldn't it be better to make a design and a rough implementation of a protocol not because of a competition, but because you truly believe there's a need for it? I know I may sound idealistic, sorry for that, but it's something I'm trying to hold on to.

If someone is trying to get funding for TLS 2.0 and cannot get it because of the consensus in this WG, they should definitely bring it to discussion on this mailing list. Otherwise I think the topic is slightly speculative.

Juho

---

From: Alfredo Pironti <[email-masked]>
Date: Wed, 16 Apr 2014 12:42:02 +0200

On Wed, Apr 16, 2014 at 12:09 PM, Juho Vähä-Herttua <[email-masked]> wrote:

> I understand the funding is a problem. Heck, I would probably start
> working on it myself if I had enough funding and a good team ready to go.
> However, I believe TLS originally succeeded not because it was the best
> design, but because it was done, worked and most importantly was the only
> reasonable candidate for its use case that could be improved together.
>
> All a competition would do is to result in a several implementations
> working differently. And because each of the teams have gotten significant
> investments from their backers, they would have a strong agenda to push it
> through one way or another, and this is where it might get ugly. Because,
> as you just said yourself, no one wants to fund an expensive project that
> is just thrown away.
>
> Wouldn't it be better to make a design and a rough implementation of a
> protocol not because of a competition, but because you truly believe
> there's a need for it? I know I may sound idealistic, sorry for that, but
> it's something I'm trying to hold on to.
>
> If someone is trying to get funding for TLS 2.0 and cannot get it because
> of the consensus in this WG, they should definitely bring it to discussion
> on this mailing list. Otherwise I think the topic is slightly speculative.
>

This is not speculative. I work in the academia, and right now I'm
refraining to invest my time (let alone funds) into a TLS proposal because,
in the absence of a call for proposals, I deem my time is better invested
in other activities.

I agree with you that, after such investment, all authors would strenuously
try to defend their proposal, and this is why selection should not come
exclusively form the authors. I also agree several proposals may eventually
merge; but, assuming the merge is better than the originals, I see this as
a positive byproduct of the call process.

That said, I'll admit that, as long as we have to stick with the current
Client/ServerHello negotiation and client speaks first, I see much of the
progress one can make being incremental, rather than radically new.

Alfredo

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 16 Apr 2014 07:28:22 -0400

Yes, I'd say that Martin's description is a more accurate statement of my view.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 Apr 2014 07:27:43 -0700

On Tue, Apr 15, 2014 at 10:32 PM, Martin Thomson
<[email-masked]>wrote:

> there.

Just as a clarifying point, I believe that what we've agreed isn't to
completely change the record layer, but rather we've agreed
(assuming there is consensus to do so) to deprecate two
of the record variants (StreamCipher and BlockCipher) in favor
of the third, AEAD, which shouldn't be changing significantly.

-Ekr

---

From: Alyssa Rowan <[email-masked]>
Date: Wed, 16 Apr 2014 23:53:10 +0100

On 16/04/2014 01:46, Trevor Perrin wrote:

> Maybe this argues for Adam Langley's earlier suggestion (also
> endorsed by a few others) that we focus on a TLS 1.3 that is a
> "tidying up" of 1.2, and push the larger goals (e.g. redesigning
> handshake for lower-latency or more encryption) to a TLS 2.0?

On reflection, I think I may favour this approach, yes:

• Keeping TLSv1.3 a cleaned-up v1.2 with better, faster, forward-secure
  baseline of fast, constant-time ECDHE and AEADs, legacy/broken lint
  removed, bugs fixed and downgrade protection, and getting that out
  fairly promptly;

  and,

• Following that with a TLSv2.0 process in which we look at the far
  more radical and challenging changes: handshake improvements,
  ClientHello/SNI encryption, perhaps a complete redesign.

If both are faster and higher-performing, that might help avoid delay
in adoption.

- -- 
/akr

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 16 Apr 2014 16:21:57 -0700

On Wed, Apr 16, 2014 at 3:53 PM, Alyssa Rowan <[email-masked]> wrote:
> * Keeping TLSv1.3 a cleaned-up v1.2 with better, faster, forward-secure
> * Following that with a TLSv2.0 process in which we look at the far

Perhaps we could do both in parallel? -

 * Start work now on a TLS 1.3 that is a cleaned-up / stripped-down
profile of TLS 1.2, without major handshake changes or new features,
aiming to finish in a few months.

 * Place a call for proposals for TLS 2.0, with the intent of choosing
one as a WG item within 4-6 months.

---

I hear the concern that people don't want a "clean-slate" or
"revolutionary" redesign of TLS, they just want to quickly make the
"minimal" changes to 5246 that meet our charter.

I'd encourage such people to re-read the charter, and look at Eric's
1.3 draft.  The goals and designs being considered are *already* a
radical break from your parent's TLS.  We'll have complex, difficult
debates involving competing visions for TLS regardless of what process
we choose.

Having different proposals is not going to create this problem.  But
it will help us navigate it, by making it easier to compare the
implications of inter-related design decisions.

Here's an example of the questions we have to resolve, and which I
think will be hard to handle with individual consensus calls if we
don't have a holistic picture of what we're choosing:

(1) Can pre-delivered public keys (via DNS? html? other?) be used to
encrypt the handshake or even app data (e.g. Andy Lutomirski's
"handshake keys" for protecting SNI, or "semi-static public keys" for
0-RTT initial connections)?

(2) Should 0-RTT reconnection be achieved via a traditional
session-ticket flow, or through a new flow based on caching a
semi-static public key?

(3) For either sort of zero-RTT reconnection, how do we design an
"anti-replay" capability which is practical and scaleable, and doesn't
leak tracking info?

(4) For zero-RTT cases, should we overlay an additional DH exchange on
the 1st RT to increase forward secrecy for subsequent data?  Or should
this be accomplished by a more general re-handshake capability?

(5) Assuming we go with the zero-RTT semi-static key approach for
reconnection, should we also re-implement the initial handshake in
terms of it (i.e. spend the 1st RT to retrieve the semi-static key),
which makes things simpler but otherwise is less optimal than
retrieving a fresh ephemeral?

(6) Should we stick with a signed-DH key agreement, or consider
alternatives (e.g. SKEME, MQV, NTor, TripleDH, other?).

(7) Should client auth be integrated into the handshake or moved to a
post-handshake, channel-bound layer?

(8) Should the protocol be integrated (somehow) with TCP or a TCP
replacement (e.g. QUIC, MinimaLT, TCPcrypt)?

(9) What should be done to minimize tracking / info-leaks in the
protocol (e.g. remove / randomize session tickets / SessionIDs, remove
other options, Elligator-type indistinguishability, more padding)?

(10) Stylistic decisions:
 - choice of ciphersuites?
 - preserve TLS message formats or replace them?
 - larger extension spaces? (end the 16-bit suffering!)

etc....

Trevor

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Apr 2014 16:45:22 -0700

> aiming to finish in a few months.

I want a pony too, but since the latency improvements are the main
reason we have people interested in TLS 1.3, I'm pretty sure that a
plan like this won't have the desired effect.  It might reduce the
volume of mail I get from this list, which is one advantage I suppose.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 Apr 2014 10:08:50 +1000

I strongly agree with the notion that bakeoffs are, at best, inadvisable. 

The IETF isn't set up to do this sort of thing; the best way to get traction here is to get implementation experience / buy-in.

Working on TLS 2 at the same time as TLS 1.3 is in active development is asking for both to fail, IMO.

Regards,

--
Mark Nottingham   http://www.mnot.net/

---

From: Andrei Popov <[email-masked]>
Date: Thu, 17 Apr 2014 00:15:56 +0000

I agree with Mark: designing and implementing two new TLS versions in parallel seems overly ambitious.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Mark Nottingham
Sent: Wednesday, April 16, 2014 5:09 PM
To: Trevor Perrin
Cc: [email-masked]
Subject: Re: [TLS] Bakeoffs

Regards,

On 17 Apr 2014, at 9:21 am, Trevor Perrin <[email-masked]> wrote:

>> * Keeping TLSv1.3 a cleaned-up v1.2 with better, faster, 
>> forward-secure  baseline of fast, constant-time ECDHE and AEADs, 
>> legacy/broken lint  removed, bugs fixed and downgrade protection, and 
>> getting that out  fairly promptly;
>> 
>>  and,
>>

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 16 Apr 2014 17:17:36 -0700

On Wed, Apr 16, 2014 at 4:45 PM, Martin Thomson
<[email-masked]> wrote:
> plan like this won't have the desired effect.

I wasn't going to bring ponies into this.

But since you started - I think the people expecting that the WG can
quickly make some "minimal" changes to 5246 that turn it into a 0-RTT,
encrypted handshake, more "privacy-friendly" protocol are the ones
being unrealistic.

If you want a quick update to 5246, then a cleanup is feasible.  If
you want everything in the charter, then we're designing a new
protocol.

I think both are valuable, and I disagree with your claim that no-one
would be interested in the former.  Several people have already
expressed interest (Adam Langley, Peter Gutmann, myself, Alyssa).

Trevor

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 16 Apr 2014 17:24:31 -0700

> I strongly agree with the notion that bakeoffs are, at best, inadvisable.

I think designing complex crypto protocols in the IETF is generally
inadvisable.  But that's what our charter sets out.

> The IETF isn't set up to do this sort of thing; the best way to get traction here is to get implementation experience / buy-in.

Agreed, but we don't have an existing 0-RTT protocol to base off
(unless people want to start with QUIC).

I think soliciting proposals and then choosing one to work on via the
WG process is the best way approximate that.

> Working on TLS 2 at the same time as TLS 1.3 is in active development is asking for both to fail, IMO.

I don't see why.  I think they'd be different efforts attracting
different folks - hopefully we could get some implementors and
practically-minded people to help clean up 1.3, while researchers /
designer-types cook up TLS 2 proposals.

Trevor

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 Apr 2014 10:44:46 +1000

> designer-types cook up TLS 2 proposals.

From an HTTP perspective, the interest in TLS 1.3 is reducing latency; taking that off the table and pushing it out to a TLS2 that's risky (both in terms of schedule and viability) isn't workable.

Regards,

---

From: Adam Langley <[email-masked]>
Date: Wed, 16 Apr 2014 17:45:23 -0700

On Wed, Apr 16, 2014 at 5:44 PM, Mark Nottingham <[email-masked]> wrote:
> taking that off the table and pushing it out to a TLS2 that's risky (both in terms of schedule and viability) isn't workable.

I think that any 0-RTT variant of TLS is risky in terms of schedule
and viability, whether it's called 1.3 or 2.0. That's the thing that
makes it risky!

Cheers

AGL

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

---

From: Patrick McManus <[email-masked]>
Date: Wed, 16 Apr 2014 21:48:36 -0400

HI All - I'm the module owner for mozilla's HTTP stack and related things.

I am very supportive of the TLS 1.3 charter because I earnestly believe it
is largely the latency issues associated with current TLS standards that
make it difficult for https to compete with http performance. The result is
more plaintext and that sucks for users. I hope addressing that will be the
focus of 1.3. There is some urgency in addressing that bottleneck - and
that urgency isn't especially compatible with a ground up rework imo .

Someone upthread hit the nail on the head for me when they said that what
is being discussed isn't really a bake off of competing solutions, but
really a CFP of competing ideas. There seems to be general agreement that
incremental improvements and standardization of existing technologies are
the areas the IETF is able to execute well in.

If a non-TLS technology is able to make a meaningful mark in this space and
then presents itself for standardization too - then that's a good problem
to have. But that is putting the cart in front of the horse by a
considerable bit.

-Patrick

---

From: Watson Ladd <[email-masked]>
Date: Wed, 16 Apr 2014 20:43:12 -0700

> From an HTTP perspective, the interest in TLS 1.3 is reducing latency; taking that off the table and pushing it out to a TLS2 that's risky (both in terms of schedule and viability) isn't workable.

Huh. Here I thought the fact that the MTI cipher suite is not secure
would be of interest.

We already have the cleaned up TLS 1.2 implemented: it's the first
three ciphersuites most browsers are offering today+Chacha and 25519.
The challenge is in documenting these changes, so that we can have
stripped down code that only offers and supports these suites, and
have interop without risky suites. (It's hard because of the install
base, but we need to start somewhere).

Remember, of the four issues TLS has today, only one
(encrypt-then-mac) has a WG draft that has been LC'd. RC4 prohibition
is en route, but no one has written a draft explaining 1/(n-1) record
splitting.

Oh, and I forgot anti-downgrade. We need that too because browsers
will happily fall back to SSLv3, where BEAST works. That seems to be
coming along fine.

0-RTT is not an easy feature. It has substantial impact on replay
protection and forward secrecy. There are fundamental theoretical
limitations in play. Furthermore, it is a misnomer: TLS happens over
TCP, which has one round trip in opening a connection already. The
best we can do on a short timescale is probably 1-RTT, by doing an
ECDH exchange where the client guesses what the server wants to see.

Sincerely,
Watson Ladd

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 16 Apr 2014 21:38:44 -0700

On Wed, Apr 16, 2014 at 6:48 PM, Patrick McManus <[email-masked]> wrote:
> focus of 1.3. There is some urgency in addressing that bottleneck - and that
> urgency isn't especially compatible with a ground up rework imo .

Unfortunately, charter goals like (encrypted handshake, 0-RTT
reconnect, privacy-friendly) do require a major rework of the TLS
handshake.  See Eric's proposal for one example [1].

Of course, there's other ways to do these things (e.g. session tickets
instead of semi-static keys for 0-RTT reconnects; TLS-inside-TLS or
renegotiation instead of semi-static keys for handshake encryption).
So I think it's worth taking the time to consider all these, instead
of rushing to paint ourselves into one corner of the design space.

Trevor

[1] http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 17 Apr 2014 09:11:31 +0200

On Wed, 2014-04-16 at 21:48 -0400, Patrick McManus wrote:

> I am very supportive of the TLS 1.3 charter because I earnestly
> believe it is largely the latency issues associated with current TLS
> standards that make it difficult for https to compete with http
> performance. The result is more plaintext and that sucks for users. I
> hope addressing that will be the focus of 1.3. There is some urgency
> in addressing that bottleneck - and that urgency isn't especially
> compatible with a ground up rework imo .

> Someone upthread hit the nail on the head for me when they said that
> what is being discussed isn't really a bake off of competing
> solutions, but really a CFP of competing ideas. There seems to be
> general agreement that incremental improvements and standardization of
> existing technologies are the areas the IETF is able to execute well
> in.

The issue is that we don't have any solutions, no other examples of
other IETF cryptographic protocols with smaller round-trip to copy from
(there is PKINIT Kerberos but that comes with issues), and
there have not been many ideas presented to reduce latency in TLS.
Thus asking the working group to produce a _new_ cryptographic protocol
in a short time frame, without any input from experts e.g., from
academia, on the topic, is not a good design practice (see WEP). 

Note that IETF typically takes an existing protocol that solves a
particular problem into action. In that case, judging from Eric's
presentation on the topic, it seems that this working group is asked to
invent a new one.

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 17 Apr 2014 09:15:41 +0200

> one as a WG item within 4-6 months.

I agree that they should be separated as activities since the more
radical and challenging changes require a different approach. 4-6 months
for proposals may be too short though.

> debates involving competing visions for TLS regardless of what process

Indeed, I believe that the most voices heard for a fast-to-be-issued TLS
1.3 that includes all the points in the charter either underestimate the
issues involved, or are unaware of them.

regards,
Nikos

---

From: Michael Sweet <[email-masked]>
Date: Thu, 17 Apr 2014 08:19:17 -0400

FWIW, 1-RTT latency is mainly an issue when you have a browser making a dozen connections to a secure site.  With HTTP/2 that particular problem goes away...

> volume of mail I get from this list, which is one advantage I suppose.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Patrick McManus <[email-masked]>
Date: Thu, 17 Apr 2014 09:41:07 -0400

On Thu, Apr 17, 2014 at 8:19 AM, Michael Sweet <[email-masked]> wrote:
>> FWIW, 1-RTT latency is mainly an issue when you have a browser making a
dozen connections to a secure site.  With HTTP/2 that particular problem
goes away...

As a browser guy I'll say I really disagree with that.

HTTP/2 is important stuff, and helps hide part of the problem, but the
latency issue continues to be an issue for HTTP over TLS use cases. Time to
first byte of course, but also to each different referenced origin (the
cdn, the third-party ad network, the identity provider, etc..). Often
things that block layout are on that cdn (e.g. stylesheets, some
javascript) so the time to perform 2 http transactions on 2 serialized tls
terminated connections is often the same as time to first screen draw. Its
considerably worse in mobile environments where RTT can be out of control.

Establishing TLS is noticeably slow, and that's a problem for the browser
use case where https often competes against http for developer mind share.
As a natural result, some content providers choose to run plaintext http
which we can all agree is an undesirable outcome. Shrinking that gap will
help.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 17 Apr 2014 10:30:46 -0400

> Unfortunately, charter goals like (encrypted handshake, 0-RTT reconnect, privacy-friendly) do require a major rework of the TLS handshake.  See Eric's proposal for one example [1].

And if it turns out that it's more work than we want to do, and that certain goals are not meant, that's okay.  " When the facts change, I change my mind. What do you do, sir?"

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 17 Apr 2014 10:32:21 -0400

I want to clarify that I wasn't personally addressing Trevor with the quote.

I was saying that we had an original goal, and as we went along it seems more complicated than we want to do, that's okay.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 17 Apr 2014 11:30:43 -0400

Patrick,

> As a browser guy I'll say I really disagree with that.

As a printer guy, I can definitely say that browsers opening dozens of connections is a major source of latency, since the printer's ability to respond to so many simultaneous connections is limited.  It's even worse when you tunnel connections over USB (IPP USB protocol) and have to multiplex requests over a limited number of channels (2 in most cases).

I'll grant that many web sites pull content from multiple servers/domains, in particular to support advertising, however it is uncommon (at least in my experience) to find all of a page's resources spread to different servers.

> HTTP/2 is important stuff, and helps hide part of the problem, but the latency issue continues to be an issue for HTTP over TLS use cases. Time to first byte of course, but also to each different referenced origin (the cdn, the third-party ad network, the identity provider, etc..). Often things that block layout are on that cdn (e.g. stylesheets, some javascript) so the time to perform 2 http transactions on 2 serialized tls terminated connections is often the same as time to first screen draw. Its considerably worse in mobile environments where RTT can be out of control.

Indeed, especially when you are opening dozens of connections before even doing a TLS handshake.

> Establishing TLS is noticeably slow, and that's a problem for the browser use case where https often competes against http for developer mind share. As a natural result, some content providers choose to run plaintext http which we can all agree is an undesirable outcome. Shrinking that gap will help.

Based on the push back in the HTTP/2 discussions on that subject, I don't think you'll get unanimous agreement on that. TLS has its place, and it is important for us to have a solid protocol to support confidential communications, but there are significant costs associated with TLS - performance, maintenance, power, money, etc. - that prevent it from being adopted wholesale today.

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 17 Apr 2014 09:59:32 -0700

Patrick McManus wrote:
> latency issue continues to be an issue for HTTP over TLS use cases. Time 
> to first byte of course  ...

Have any server operators tried using a small-ish (somewhat less than 1500
bytes) TLS record size to reduce time-to-first-byte at the browser?

What were the results?

Mike

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 17 Apr 2014 13:53:10 -0400

Google changed the size to fit into a common TCP packet and found it highly worthwhile
    http://www.igvita.com/2013/10/24/optimizing-tls-record-size-and-buffering-latency/

---

From: Sean Turner <[email-masked]>
Date: Thu, 17 Apr 2014 16:58:32 -0400

On Apr 15, 2014, at 21:19, Watson Ladd <[email-masked]> wrote:

> correctly this time what he failed to do correctly twice before? 

Watson,

Please stop the personal attacks.  The IETF published the TLS RFCs after the IETF consensus process is run.  That process includes the WG reaching consensus (sometimes rough), the wider IETF community reaching consensus, and the entire IESG reviewing the WG’s specification.  Ownership of any failings is to be shared by a very wide community.

spt (as chair)

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Fri, 18 Apr 2014 15:19:46 +0300

> On 16.4.2014, at 13.42, Alfredo Pironti <[email-masked]> wrote:
> 
> This is not speculative. I work in the academia, and right now I'm refraining to invest my time (let alone funds) into a TLS proposal because, in the absence of a call for proposals, I deem my time is better invested in other activities.

Thanks for coming forward, so I stand corrected that the issue is not speculative.

> That said, I'll admit that, as long as we have to stick with the current Client/ServerHello negotiation and client speaks first, I see much of the progress one can make being incremental, rather than radically new.

Let's just hope the discussion keeps going after the TLSv1.3 issue is resolved. The WG had a lot of inactivity between TLSv1.2 and now that could have been used better, but it seems that only after several big exploits people are suddenly interested in TLS again.

Juho

---

From: Alfredo Pironti <[email-masked]>
Date: Fri, 18 Apr 2014 15:01:41 +0200

> Thanks for coming forward, so I stand corrected that the issue is not

Well, it's just me ;-)

> Let's just hope the discussion keeps going after the TLSv1.3 issue is
> resolved. The WG had a lot of inactivity between TLSv1.2 and now that could
> have been used better, but it seems that only after several big exploits
> people are suddenly interested in TLS again.
>

After all, I do agree with the chairs that progress on TLS is more urgent
than meta-discussion (so, sorry chairs for keeping this thread alive! I'll
stop now!). And although seeing handshake messages encapsulated in
ClientHello extensions does make me feel a bit sick, I acknowledge that,
without changing the well-known port for "protocol x over TLS", none of the
radical changes I'd like to see can happen.

Alfredo

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 18 Apr 2014 21:15:22 -0700

> Working on TLS 2 at the same time as TLS 1.3 is in active development is asking for both to fail, IMO.

+1

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 18 Apr 2014 21:37:39 -0700

My apologies for sending this. Since I use a threaded email reader, I did not see the "Concluding the TLS process thread” until after I sent this.