Re: [TLS] TLS 1.3 process

Nikos Mavrogiannopoulos <nmav@redhat.com> Fri, 28 March 2014 12:21 UTC

Return-Path: <nmav@redhat.com>
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 93A131A05C3 for <tls@ietfa.amsl.com>; Fri, 28 Mar 2014 05:21:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 irJHGAfu2T5o for <tls@ietfa.amsl.com>; Fri, 28 Mar 2014 05:21:12 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 266821A0430 for <tls@ietf.org>; Fri, 28 Mar 2014 05:21:11 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2SCL1R9005738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Mar 2014 08:21:01 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2SCKpTg022778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Mar 2014 08:20:58 -0400
Message-ID: <1396009251.19721.76.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Fri, 28 Mar 2014 13:20:51 +0100
In-Reply-To: <5335581D.3020608@cs.tcd.ie>
References: <9A043F3CF02CD34C8E74AC1594475C7372394B5F@uxcn10-6.UoA.auckland.ac.nz> <5335581D.3020608@cs.tcd.ie>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0CQ5UWJ6SkOVUXtcX74nlmKfGmY
Cc: tls@ietf.org
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 12:21:15 -0000

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.

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

regards,
Nikos