Subject: Re: [TLS] TLS 1.3 process

From: Peter Gutmann <[email-masked]>
Date: Fri, 28 Mar 2014 03:32:24 +0000

Trevor Perrin <[email-masked]> writes:

>* 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.

+1.  I haven't said much so far because it seems the 1.3 effort is making
steady progress towards the design-by-committee mess that make IKEv1/IPsec
such a winner, but I would much prefer the approach of "set boundaries, people
have six months to submit designs, and then a bake-off".  TLS 1.2, which
seemed to consist mostly of gratuitous tweaking of 1.1, has taken years to see
any uptake (SSL Pulse says about 30%, only slightly above SSLv2, and that's
for the Alexa top 200K, not the entire net, which I'd expect to be far worse
than that), if 1.3 is even more of 1.2 then who knows how long that'll take
before we see any real uptake.

In fact I'd be prepared to argue that any work on TLS 1.3 or 2 or whatever
it's going to be is premature when the vast majority of the net doesn't even
do TLS 1.1 yet, let alone 1.2.  What we'll end up with is a bunch of major
sites doing it and, over a period of several years, browsers gradually
introducing support (Firefox took what, five years?).  So if the history of
TLS 1.1/1.2 is anything to go by, anything we standardise now may start
seeing significant deployment in about the 2020-2025 time frame.

Peter.

---

From: t.petch <[email-masked]>
Date: Fri, 28 Mar 2014 10:14:14 +0000

----- Original Message -----
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>
Sent: Friday, March 28, 2014 3:32 AM
> Trevor Perrin <[email-masked]> writes:
<snip>
> seeing significant deployment in about the 2020-2025 time frame.

True, but I see another requirement on the TLS WG.  As and when we
become aware of a new and credible threat, then we should develop a
counter for it so that when disaster strikes some part of the Internet
as a result of an attack based on the threat, we can say, 'Here is the
solution, go implement'.

Tom Petch

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 Mar 2014 11:08:13 +0000

Peter,

On 03/28/2014 03:32 AM, Peter Gutmann wrote:
>  I haven't said much so far because it seems the 1.3 effort is making
> such a winner, 

I'm sure others who were more involved will correct me,
but wasn't the IKEv1 fun in large part caused by not
being able to pick a winner from not-hugely-different
competing proposals, with a sprinkling of not easily
handled personalities and other competing interests
involved?

Quoting a recent mail from Jeff Schiller [1]:

"The real (or at least the first) problem with the IPSEC working group
was that we had a good and simple solution, Photuris. However the
document editor on the standard decided to claim it (Photuris) as his
intellectual property and that others couldn’t recommend changes
without his approval. This effectively made Photuris toxic in the
working group and we had to move on to other solutions. This is one of
the events that lead to the IETF’s “Note Well” document and clear
policy on the IP associated with contributions. Then there was the
ISAKMP (yes, an NSA proposal) vs. SKIP. As Security AD, I eventually
had to choose between those two standards because the working group
could not generate consensus. I believed strongly enough that we
needed an IPSEC solution so I decided to choose (as I promised the
working group I would do if they failed to!). I chose ISAKMP. I posted
a message with my rationale to the IPSEC mailing list, I’m sure it is
still in the archives. I believe that was in 1996 (I still have a copy
somewhere in my personal archives)."

But anyway, while we don't need to reprise the details of
that bit of history, I'm sure we all do agree that not
repeating the IKEv1 fun is a high priority goal here and
I'm also sure the chairs and many WG participants are
taking that into account. (And I'm quite sure the WG
just don't want to end up with me having to toss a coin
to pick a winner:-)

So, FWIW, the chairs process plan seems reasonable to me
but its also good to see the WG discussing that.

S.

[1]
http://www.metzdowd.com/pipermail/cryptography/2013-September/017391.html

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 28 Mar 2014 13:20:51 +0100

> handled personalities and other competing interests

Yes, but I don't think that we can deduct from the issue that
competition is bad. I don't know what the details where in the case you
describe, and whether the author was justified for refusing changes, but
I think that a working group can make clear that any accepted solution
will be improved during the WG process.

Competition has worked for the TLS protocol, as SSL 3.0 was not product
of IETF, but rather the result of competition between SSL from Netscape
and PCT by Microsoft, and for its time it was state of the art. The
contribution of IETF was minor changes to SSL 3.0 to obtain TLS 1.0 and
later by fixing open issues.

However, the majority of the TLS protocol was designed outside the IETF
processes, and the result I believe was more than satisfactory.

regards,
Nikos

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 28 Mar 2014 13:56:07 -0700 (PDT)

> later by fixing open issues.

  The problems with IKEv1 had nothing to do with competition
and everything to do with a naive belief that it was possible to
satisfy everyone.

  IMO, the author was not justified for refusing changes. I remember
a presentation in IETF 34 or 35 (forget which) in which Hugo Krawczyk
presented very reasonable changes to Photuris that Bill Simpson refused
to entertain. That was, in my view, the beginning of the end.

  The difference between SKIP and ISAKMP/IKE was actually profound.
Key management with SKIP was integrated with the data being sent
and the notion of an IPsec SA was kind of muddied. IKE was more like
Photuris in that respect as a separate key management protocol for
creating IPsec SAs. There was a competition and choice made.

  Then the problems started with contradicting "requirements" from
vocal and opinionated people-- need keys to be authenticated not
just identities and also we need identity protection, etc-- that ended
up with option being piled on top of option creating a mess.

  Competition worked in the IPsec WG and it can work in the TLS WG
too. The "winner" just needs to be forceful in saying no to people
and the chairs have to call consensus and move the group along when
decisions are made.

  Dan.