Re: [TLS] Fixing TLS

Dave Garrett <davemgarrett@gmail.com> Tue, 12 January 2016 17:02 UTC

Return-Path: <davemgarrett@gmail.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 4CC281B2B5D for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 09:02:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 aO6JKdp6XC3N for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 09:02:36 -0800 (PST)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBBF71B2B50 for <tls@ietf.org>; Tue, 12 Jan 2016 09:02:28 -0800 (PST)
Received: by mail-qg0-x235.google.com with SMTP id e32so344476024qgf.3 for <tls@ietf.org>; Tue, 12 Jan 2016 09:02:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=Pd0GIYDEMMI3QIP4lX9Amf25IMwLQK42vRTXIka7r0g=; b=xZF8bodmeDdjA7etGb+22OHtjZO8ICQ0nZ6heKevINDovtVUZj3gxMJX/KUdhD65sz ynZeO9mU+YNKFRblBVKGYHA6kCWMloG89QJtohCy9BoyQedBF0xBx2FJNyTahAKgXNa2 o7JaaO1K7Gc9wHNnVPS7L+PGizs4v5fhFb9wwxVSzytAUZT/ZSsoSfKpfNzLq/DhIy57 flV7lJMd5LACmdqjSNsWWjf2oL4hx7O1tlMQ2o21IAeDkOl4Pd8r617xI7ZBr8PjT7Tr MLe03K1Bkao1WrRTYxjTPzgbDY/ZFtiE9t5hEh5E+aPlBIVlfEBaXLOl2ihUcVBU5AvJ xToA==
X-Received: by 10.140.19.52 with SMTP id 49mr170228473qgg.65.1452618148181; Tue, 12 Jan 2016 09:02:28 -0800 (PST)
Received: from dave-laptop.localnet (pool-72-94-152-197.phlapa.fios.verizon.net. [72.94.152.197]) by smtp.gmail.com with ESMTPSA id s188sm52168176qhc.41.2016.01.12.09.02.27 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 12 Jan 2016 09:02:27 -0800 (PST)
From: Dave Garrett <davemgarrett@gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Date: Tue, 12 Jan 2016 12:02:26 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4BC6849@uxcn10-5.UoA.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201601121202.26624.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/fuYe6sPc7JNrEEMFZyRhOFEw9ZU>
Cc: tls@ietf.org
Subject: Re: [TLS] Fixing TLS
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 12 Jan 2016 17:02:37 -0000

On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote:
> Martin's comment reminded me of the following that I've been meaning to
> post...
> 
> In a recent discussion among some crypto folks, the topic of what TLS 1.3
> could be came up.  Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path from
> TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is.  The discussion
> centered around the fact that we already have lots of analysis done for TLS
> 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3
> problems while being as compatible as possible with existing infrastructure.
> So what this would do is take existing security analysis applied to TLS,
[...]

Welcome to the TLS 1.2.1 proposal club. Unfortunately, we don't have snacks.

I'll be the bearer of bad news and tell you that your proposal has come up in multiple forms. I suggested a similar thing a while back and far before me others have as well. The chairs have, however, long declared consensus that we want to focus on a single new version not leaving out other more complex changes, namely latency improvements. The primary argument is that TLS version adoption rates are horrible and we would be far better suited to one major upgrade rather than incremental changes that would likely inhibit adoption of the more complex changes that we also need. (just a quick summary from my view; someone else can chime in here if they need to)

I can't dispute this position, though personally I think it's not the best move. That said, if we were going to do a more incremental TLS version, doing it along side HTTP/2 to avoid the messy TLS restrictions it ended up with would have been the way to go. That ship has sailed, and we're now well into TLS 1.3 development, so I guess I'm now on board with working to finalize the work that we're already doing (frankly, with a rename to TLS 2.0 being a good idea). If you can somehow drum up consensus to overturn the previous consensus, more power to you, but I think that's not likely to be the best route anymore.


Dave