Re: [TLS] Bakeoffs

Nikos Mavrogiannopoulos <nmav@redhat.com> Thu, 17 April 2014 07:11 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 DE6DF1A0075 for <tls@ietfa.amsl.com>; Thu, 17 Apr 2014 00:11:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.174
X-Spam-Level:
X-Spam-Status: No, score=-7.174 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 DBzxJS1QN3cB for <tls@ietfa.amsl.com>; Thu, 17 Apr 2014 00:11:38 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1111E1A00DD for <tls@ietf.org>; Thu, 17 Apr 2014 00:11:38 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3H7BXbj005770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 17 Apr 2014 03:11:34 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s3H7BVgm012593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 17 Apr 2014 03:11:32 -0400
Message-ID: <1397718691.12647.37.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Date: Thu, 17 Apr 2014 09:11:31 +0200
In-Reply-To: <CAOdDvNpCumG+mqK7NBNxcN97aK9mrbfsQHLziYZ4AazpOpq-EQ@mail.gmail.com>
References: <FAD11A6F-DB65-4797-89C2-022DCDED266F@iii.ca> <CACsn0ck5u_Sy7tvAbiT0mwRz0rkw4ZBW23F3R8qBV0urFEq21w@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B4905A5@USMBX1.msg.corp.akamai.com> <CAGZ8ZG1C8L1LW=H__FCiuK-Ywq_c63-pxW39QoCR6f0k1wd2Xg@mail.gmail.com> <534F09D6.1060308@akr.io> <CAGZ8ZG0kCxBa44cSrwF9kjsutp=ooR3QV98OWueFBZga79tMHA@mail.gmail.com> <B245232B-A552-4407-9EED-64E327A15308@mnot.net> <CAGZ8ZG3-qbfxFyGKydq4uAKdeRBaQrNp8=+aE=h2LFst8tS+0w@mail.gmail.com> <397F06BC-7B38-4A86-9BF9-E936232E6130@mnot.net> <CAMfhd9WQ22o2Tbh=0fv1aYEOjpuir-RJ4uL8DhuYR+tzny=QCA@mail.gmail.com> <CAOdDvNpCumG+mqK7NBNxcN97aK9mrbfsQHLziYZ4AazpOpq-EQ@mail.gmail.com>
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.27
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1t0_N3WuMMdBzx_oUFAImR7cTUA
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Bakeoffs
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: Thu, 17 Apr 2014 07:11:40 -0000

On Wed, 2014-04-16 at 21:48 -0400, Patrick McManus wrote:

> I am very supportive of the TLS 1.3 charter because I earnestly
> believe it is largely the latency issues associated with current TLS
> standards that make it difficult for https to compete with http
> performance. The result is more plaintext and that sucks for users. I
> hope addressing that will be the focus of 1.3. There is some urgency
> in addressing that bottleneck - and that urgency isn't especially
> compatible with a ground up rework imo .

> Someone upthread hit the nail on the head for me when they said that
> what is being discussed isn't really a bake off of competing
> solutions, but really a CFP of competing ideas. There seems to be
> general agreement that incremental improvements and standardization of
> existing technologies are the areas the IETF is able to execute well
> in.

The issue is that we don't have any solutions, no other examples of
other IETF cryptographic protocols with smaller round-trip to copy from
(there is PKINIT Kerberos but that comes with issues), and
there have not been many ideas presented to reduce latency in TLS.
Thus asking the working group to produce a _new_ cryptographic protocol
in a short time frame, without any input from experts e.g., from
academia, on the topic, is not a good design practice (see WEP). 

Note that IETF typically takes an existing protocol that solves a
particular problem into action. In that case, judging from Eric's
presentation on the topic, it seems that this working group is asked to
invent a new one.

regards,
Nikos