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
- [TLS] TLS 1.3 process Sean Turner
- Re: [TLS] TLS 1.3 process Trevor Perrin
- Re: [TLS] TLS 1.3 process Watson Ladd
- Re: [TLS] TLS 1.3 process Martin Thomson
- Re: [TLS] TLS 1.3 process Trevor Perrin
- Re: [TLS] TLS 1.3 process Salz, Rich
- Re: [TLS] TLS 1.3 process Peter Gutmann
- Re: [TLS] TLS 1.3 process Nikos Mavrogiannopoulos
- Re: [TLS] TLS 1.3 process t.petch
- Re: [TLS] TLS 1.3 process Stephen Farrell
- Re: [TLS] TLS 1.3 process Nikos Mavrogiannopoulos
- Re: [TLS] TLS 1.3 process Douglas Stebila
- Re: [TLS] TLS 1.3 process Salz, Rich
- Re: [TLS] TLS 1.3 process Watson Ladd
- Re: [TLS] TLS 1.3 process Dan Harkins
- Re: [TLS] TLS 1.3 process Nikos Mavrogiannopoulos
- Re: [TLS] TLS 1.3 process Adam Langley
- Re: [TLS] TLS 1.3 process Eric Rescorla
- Re: [TLS] TLS 1.3 process Watson Ladd
- Re: [TLS] TLS 1.3 process Trevor Perrin
- Re: [TLS] TLS 1.3 process Bill Frantz
- Re: [TLS] TLS 1.3 process Eric Rescorla
- Re: [TLS] TLS 1.3 process Dan Harkins
- Re: [TLS] TLS 1.3 process Peter Gutmann
- Re: [TLS] TLS 1.3 process Peter Gutmann
- Re: [TLS] TLS 1.3 process Peter Gutmann
- Re: [TLS] TLS 1.3 process Bill Frantz
- Re: [TLS] TLS 1.3 process Dan Harkins
- Re: [TLS] TLS 1.3 process Salz, Rich
- Re: [TLS] TLS 1.3 process Peter Gutmann
- Re: [TLS] TLS 1.3 process Bill Frantz
- Re: [TLS] TLS 1.3 process Dan Harkins
- Re: [TLS] TLS 1.3 process Watson Ladd
- Re: [TLS] TLS 1.3 process Dan Harkins
- Re: [TLS] TLS 1.3 process Peter Gutmann
- Re: [TLS] TLS 1.3 process Andy Lutomirski
- Re: [TLS] TLS 1.3 process henry.story@bblfish.net