[TLS] Proposal: a minimal TLS 1.3 for HTTP/2

Dave Garrett <davemgarrett@gmail.com> Mon, 03 November 2014 21:51 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 4EFA71A1A0F for <tls@ietfa.amsl.com>; Mon, 3 Nov 2014 13:51:14 -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 P0rO2WB1WAA6 for <tls@ietfa.amsl.com>; Mon, 3 Nov 2014 13:51:12 -0800 (PST)
Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087EE1A1A12 for <tls@ietf.org>; Mon, 3 Nov 2014 13:51:11 -0800 (PST)
Received: by mail-qa0-f52.google.com with SMTP id u7so8888194qaz.39 for <tls@ietf.org>; Mon, 03 Nov 2014 13:51:11 -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:mime-version:content-type :content-transfer-encoding:message-id; bh=NYbjcoc8dh9BbyUi8aeJ4fcGOHfKGe7B4Hi6bwUW1+k=; b=kk5ZEXv7vFNW/YTAjJ4KmHirDqlBbisrNrGNfOhDPKs2nOi6I8+OULlEfcPrV85X5+ +fPoG3W3Fmp1yO0xmarl57ynvgOpP5ZmgsGRJdL3PuLtWmTKQR9OA0maJBAS5nGmvJSP WY7+v/3S0M62p9Psj12Fmp/zoLrF+4dJMEqR+dWUfNw6d/mmuZLP0S78iNQ/xZ5hypFk 4wSbkFPXyjo3JhU5KFZSZpHTiv/Xqz4P7dNJMsgKrWN+128GvJ2f8ilroHSf+1RQoF8O trclCLpPIjvCT+ZQNQJ7S5aOuobBZxf4RQ07Kyxs6fV5iQMY4YuLRdxQWso0wtquHc4U G50A==
X-Received: by 10.140.101.120 with SMTP id t111mr65903558qge.6.1415051471188; Mon, 03 Nov 2014 13:51:11 -0800 (PST)
Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id e49sm17880350qgf.15.2014.11.03.13.51.10 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 03 Nov 2014 13:51:10 -0800 (PST)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Mon, 03 Nov 2014 16:51:09 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-66-generic-pae; KDE/4.4.5; i686; ; )
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201411031651.09896.davemgarrett@gmail.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pNp8gPaueT9qxK1S7eblNCHra3A
X-Mailman-Approved-At: Wed, 05 Nov 2014 15:11:01 -0800
Cc: ietf-http-wg@w3.org
Subject: [TLS] Proposal: a minimal TLS 1.3 for HTTP/2
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: Mon, 03 Nov 2014 21:51:14 -0000

It was suggested by an HTTP WG member that I propose this on the TLS WG list. HTTP WG list CCed.

TL;DR: Please publish an improved TLS spec for HTTP/2 before working on an ideal one.

HTTP/2 has a problem: Section 9.2.2 of the current draft imposes security restrictions onto the 
usage of TLS that some implementors believe may be difficult to properly handle based on their various 
situations. There are interoperability issues that must be considered because of it. There would be 
new interoperability issues if it were to be removed at this late stage.

The general consensus, I believe, is that 9.2.2 imposes reasonable restrictions, however these 
restrictions do not ideally belong in an HTTP spec but rather a TLS spec. The pre-existing system to 
negotiate this topic is the TLS version, however TLS 1.3 is not and will not be ready in time for a 
final HTTP/2 specification. Section 9.2.2 could possibly be passed with some modification, however it 
is not the ideal solution.

I would like to propose a relatively simple solution:

1) Move the current TLS 1.3 draft and all future development to TLS 1.4
2) Write a new TLS 1.3 draft based on TLS 1.2 with no compression and requiring AEAD and FS
3) Rewrite HTTP/2 section 9.2 with a requirement of TLS 1.3 instead of TLS 1.2 with restrictions

This is more appropriately a proposal for a TLS 1.2.1, however the versioning scheme is not set up 
to handle this.

The goal of this proposal is to merely take the TLS requirements that are desired for HTTP/2 and to 
publish them in a separate, more appropriate specification. This would notably simplify negotiating a 
valid HTTP/2 connection over TLS. A streamlined TLS 1.3 spec would also be available for usage with 
HTTP/1.1 connections as well as any other applications. This would make setting up properly 
configured TLS far simpler, as mitigations for known-bad portions of the TLS 1.2 spec would no longer 
be needed. (e.g. compression & RC4 need not be disabled; they are not supported in TLS 1.3) The 
minimum key size requirements of 9.2.2 could also be added to make them far easier to enforce.

This TLS 1.3 proposal contains nothing fundamentally new. It merely aims to remove old no longer 
acceptable portions of the spec in order to simplify the process of implementing modern standards. 
As such, it would maintain on-the-wire compatibility with TLS 1.2 with the sole exception of the 
version number. The only differences would be restrictions what can be negotiated. The process of 
implementing and testing this would be relatively simple, making it feasible to finalize within the 
timeframe needed to be mandated by HTTP/2. (with possibly only a small delay, which already seems to 
be a possibility)


Dave