Re: [TLS] TLS 1.3 process

Peter Gutmann <> Sat, 29 March 2014 06:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 400CE1A077B for <>; Fri, 28 Mar 2014 23:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.51
X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BxxXGX-ETPkp for <>; Fri, 28 Mar 2014 23:32:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 983DE1A0775 for <>; Fri, 28 Mar 2014 23:32:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=uoa; t=1396074732; x=1427610732; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=co7TWM748D2UQCqRxCyMQ3e72ArFNqRHfspdgWF9jgA=; b=hMRRsti4tTatstizX/GqK5U4GP3+8+s38mIS0mN/kR/bpKTNdjhnvUGM Fsvk7uLtieXqzdJvB1vC7oYtoOJBrSCufBHbZn7gcrtRaKAZWXtw29gmY ioEnU2THKaShtXT0Mev1k4hd4Voam+zx/a36y+x/N+aStwrxboXOLZQut 4=;
X-IronPort-AV: E=Sophos;i="4.97,755,1389697200"; d="scan'208";a="243517826"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 29 Mar 2014 19:32:08 +1300
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Sat, 29 Mar 2014 19:32:07 +1300
From: Peter Gutmann <>
To: "<>" <>
Thread-Topic: [TLS] TLS 1.3 process
Thread-Index: Ac9LGJtcwnMdIAC6QBS+Ty3Vj5y3QQ==
Date: Sat, 29 Mar 2014 06:32:07 +0000
Message-ID: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] TLS 1.3 process
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 29 Mar 2014 06:32:17 -0000

Stephen Farrell <> 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 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.