Re: [TLS] TLS 1.3 process

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 28 March 2014 11:08 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D421A0522 for <tls@ietfa.amsl.com>; Fri, 28 Mar 2014 04:08:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6MTCPiZGYOd for <tls@ietfa.amsl.com>; Fri, 28 Mar 2014 04:08:16 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id ECB951A0535 for <tls@ietf.org>; Fri, 28 Mar 2014 04:08:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E237CBE9C; Fri, 28 Mar 2014 11:08:11 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ3dr7W8aUPf; Fri, 28 Mar 2014 11:08:11 +0000 (GMT)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B8EF3BE83; Fri, 28 Mar 2014 11:08:11 +0000 (GMT)
Message-ID: <5335581D.3020608@cs.tcd.ie>
Date: Fri, 28 Mar 2014 11:08:13 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, "<tls@ietf.org>" <tls@ietf.org>
References: <9A043F3CF02CD34C8E74AC1594475C7372394B5F@uxcn10-6.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7372394B5F@uxcn10-6.UoA.auckland.ac.nz>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-Y9PgABRoVdJshCdq9Bl_fsAOuY
Subject: Re: [TLS] TLS 1.3 process
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Mar 2014 11:08:21 -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
> 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?

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