Re: [TLS] TLS 1.3 process

Nikos Mavrogiannopoulos <nmav@redhat.com> Fri, 28 March 2014 15:14 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 3DA001A0919 for <tls@ietfa.amsl.com>; Fri, 28 Mar 2014 08:14:38 -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 XDwva4jVsbBc for <tls@ietfa.amsl.com>; Fri, 28 Mar 2014 08:14:36 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1EF1A0668 for <tls@ietf.org>; Fri, 28 Mar 2014 08:14:36 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2SFEWDx010258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Mar 2014 11:14:33 -0400
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2SEeCsR021401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Mar 2014 10:40:13 -0400
Message-ID: <1396017612.19721.110.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: "Salz, Rich" <rsalz@akamai.com>
Date: Fri, 28 Mar 2014 15:40:12 +0100
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE833@USMBX1.msg.corp.akamai.com>
References: <AF370E26-CA97-4CE3-9CC7-2F0939FE2B71@ieca.com> <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE833@USMBX1.msg.corp.akamai.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.23
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OPWEx2xqpC30ag8seXXR3NUe9Jw
Cc: "<tls@ietf.org>" <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 15:14:38 -0000

On Fri, 2014-03-28 at 10:12 -0400, Salz, Rich wrote:
> > The TLS WG charter is pretty clear that the intention isn't to design a completely new protocol but rather to revise TLS,
> > and specifically to "place a priority in minimizing gratuitous changes to TLS."
> +1.
> 
> It seems to me that there are almost three viewpoints within this WG.  With the hope that I'm equally unfair to everyone, I'd summarize them like this:
> 	- Update to modern crypto knowledge to fix bugs, and some modern features and be done
> 	- Make big changes to fix serious problems
> 	- Start over from a clean sheet; "I don't know what it will be, but we'll call it TLS."
> I put myself in the first group (except for SNI encryption, which will get a separate post :), could be convinced to support something from the second once it's written down, and am probably not qualified to evaluate anything from the third group (few people are). Interestingly, barring divine intervention, the above list is probably in order of length of time needed, as well. That would seem to indicate that there's room for all three efforts here.

This is not my impression of the discussions and the meetings. Eric in
the last meetings has presented a list of changes to the protocol that
really exceeds the "Update to modern crypto knowledge to fix bugs, and
some modern features and be done", (whatever that means).

So my understanding is that there will be big changes (e.g., reducing
handshake messages, redesign of handshake to encrypt everything) to fix
serious and not serious problems (e.g., reducing the round-trips), and
the question is whether to do it:
1. within the working group (which is stated to have no crypto
expertise).
2. by using external expertise.

regards,
Nikos