Re: [TLS] TLS 1.3 process

["Dan Harkins" <[e-mail]>]

On Fri, March 28, 2014 5:20 am, Nikos Mavrogiannopoulos wrote:
> On Fri, 2014-03-28 at 11:08 +0000, Stephen Farrell wrote:
>> 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
>> > steady progress towards the design-by-committee mess that make
>> IKEv1/IPsec
>> > 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?
>
> 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.

  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.