Re: [TLS] TLS 1.3 process

[Peter Gutmann <[e-mail]>]

Stephen Farrell <[e-mail]> writes:

>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?

>From Jeff Schiller's comment and recollections by others who were involved it
was more a problem of politics, the authors of Photuris were either difficult
to work with or unwilling to compromise their elegant design depending on
which side you're on so Photuris couldn't be used, SKIP was from Sun so that
couldn't be used, and the result was a design-by-committee mess.

Also, the solution isn't necessarily a competition per se but the way that the
competition channels the design.  What's needed is an elegant design created
by a very small number of talented people, not the outcome of several years of
horse-trading put in an RFC.  Look at all of the successful mainstream
Internet security protocols: SSL, three people.  S/MIME, two(?) people.  PGP,
one person. SSH... well, it started out with a small number of people at
SSH.com and then got hacked and kludged endlessly, but close enough.

The competition format more or less requires the "small group of talented
individuals" design, you can't submit a design-by-committee entry to a
competition because (a) a committee will never agree on a single design before
the competition closes and (b) the committee design will be such a mess that
it'll never get picked.

My preference (which I've expressed off-list) would be just to take SKEME,
come up with a single unambiguous profile for it (not the kitchen-sink IPsec
interpretation), and call that TLS 2.0.  The crypto framework is already
there, you just need to provide a wire format for it and nail down a single
interpretation that everyone speaks.

Peter.