[TLS] Does the ServerHello really need unencrypted extensions at all?

Dave Garrett <davemgarrett@gmail.com> Sun, 19 July 2015 01:22 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 []) by ietfa.amsl.com (Postfix) with ESMTP id CA8B41A1BC0 for <tls@ietfa.amsl.com>; Sat, 18 Jul 2015 18:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id HskhN5Is5vBA for <tls@ietfa.amsl.com>; Sat, 18 Jul 2015 18:22:16 -0700 (PDT)
Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (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 28B4A1A1BBC for <tls@ietf.org>; Sat, 18 Jul 2015 18:22:15 -0700 (PDT)
Received: by qgeu79 with SMTP id u79so5605634qge.1 for <tls@ietf.org>; Sat, 18 Jul 2015 18:22:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=WShOgCQ40rqtojgPNmLkLBUiH+OrT+ynrJ2fmPIFTZQ=; b=TWQrubY51aTDwp8QLArFQiUX92LWjjj+YFUEiSU6y6zzK2RPEkozjJ4pOzDvJN0PIQ VOvFOUBkm2H4x4uGsAREZW1RdsS2Ijn1vRpEC2XChppcc7xzdK8bGDQ66GbR/z5eFayp Jy4giKkb/D3CskwlHq7YsrmzkdyIWyL/93wVNzA6Qk2iPLmrFeROEPKHGXSgZfzPmzlL 0/S8OlkIp9Tt+whATTSjX405zy/yHQzuTBz4zjLpCoMkPMxZ2sdNr7Twxqy3Cg2L3SOQ lwWMJrUGI7W2JmZJtMsh6YO6X+XPFyzhpGlxcEEuTi2tmFUHRGKtWaIrk4NY57CvjocF s6ZA==
X-Received: by with SMTP id 140mr31260272qhx.57.1437268935242; Sat, 18 Jul 2015 18:22:15 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. []) by smtp.gmail.com with ESMTPSA id t77sm2508797qge.42.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 18 Jul 2015 18:22:14 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>, Eric Rescorla <ekr@rtfm.com>
Date: Sat, 18 Jul 2015 21:22:12 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201507182122.12566.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/trHgRX7uUYzvcDE7pF4VyoFfsNA>
Subject: [TLS] Does the ServerHello really need unencrypted extensions at all?
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: Sun, 19 Jul 2015 01:22:18 -0000

There's two issues (basically duplicates) for this topic, as well as an inline TODO.

The current expectation is to separate extensions into unencrypted and encrypted, with:
"The ServerHello MUST only include extensions which are required to establish the cryptographic context."

The rest then go into the new EncryptedExtensions message.

Are there really any extensions that this applies to? What extension couldn't we get away with encrypting? As soon as ServerKeyShare is sent, the client should have enough information to decrypt the encrypted extensions message.

Site note: ServerKeyShare could probably just be merged into ServerHello at this point:

   struct {
       ProtocolVersion server_version;
       Random random;
       CipherSuite cipher_suite;
       select (DH) {
           case true:
               NamedGroup group;
               opaque key_exchange<1..2^16-1>;
           case false:
               struct {};
   } ServerHello;

Even if an extension is desired to set up a cryptographic context, then ideally you'd want to set up a basic extension-less one _first_, send an encrypted extensions message containing that needed extension, then send a second encrypted extensions message using the new context using the extension. The goal is to encrypt all the things, per TLS WG charter, so I don't see a point in allowing unencrypted extensions in ServerHellos at all anymore.

Is there some reason why such a plan wouldn't be able to work? Having two places to put server extensions is bound to cause mistakes.