[TLS] Extensions "supported_groups" and "key_share" in TLS 1.3

Xuelei Fan <xuelei.fan@vimino.com> Thu, 26 November 2015 13:52 UTC

Return-Path: <xuelei.fan@vimino.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 2FBE21B39D7 for <tls@ietfa.amsl.com>; Thu, 26 Nov 2015 05:52:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 80M0aO8N0hy6 for <tls@ietfa.amsl.com>; Thu, 26 Nov 2015 05:52:37 -0800 (PST)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (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 B30641B39D5 for <tls@ietf.org>; Thu, 26 Nov 2015 05:52:37 -0800 (PST)
Received: by obbbj7 with SMTP id bj7so63147782obb.1 for <tls@ietf.org>; Thu, 26 Nov 2015 05:52:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=CjxzeEKMVHcfJJEOO0dwgbXXfPZ9zGPPip6Wk928/8E=; b=owfJ5PU/vJCK5hv9NeMd7KYHbckYvLRz0tWrwQirrGbRA/SDfQlTFxW/YGU78IGgx1 WC6eOrXVoVKTWR61sv9ISvpDlal+MTVKC30VsWHQZ2LsG9gHGyrkKAokHVfCcWgETf4c K+iUq6y84CJ4ZjSjucaMC02/AUEXN2kdh+blrk1LiaywgLQxRhmZWoidxs1JjaGDl416 tEPdkBUVVLX42kXZ9RaR/WACtIFqWkWBAVipjhoKlCgZPa7/K12esQX9dPq8Rp8F3Dw+ +3jgYvruBwxkrQizdaVNYDwFZLlYuggWMopHnIvyHmvnDbpuhPA88RcJbt4zCiIwVf5y zF1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=CjxzeEKMVHcfJJEOO0dwgbXXfPZ9zGPPip6Wk928/8E=; b=kzTlQmmxtR6Px5uxFVi6rmzNFECRwMzTZ4RI0zkimjAVO1EQNiKWulM2+qsmGh4Zx+ Xdkyo/x2frgwGQ8N8KOH/n5A+oGoIPzrviFzSeZ5FeU0t26ehBwjW/09qtji7lz0asey CEFtBSbJO8xRKxxlFfYTjpTemingqbiaf8XmXdn6gHSv1dlFZY61aBjloWGMkxvSkPsg 4u+yB5QQBVVLfBs85ORtSNyc8dp+Pg397P+yyacc74pgGaVsDZTSoimboBcTUMCoxv4Y kttE4Lf82VtrpZ3GqqIm9vR8Uuij8ARR9LP2abuMnjg8xkPc6SF5nVW0KIEP4wNWHR6M tYNQ==
X-Gm-Message-State: ALoCoQlzr7MPRmvA9qdVWgqr8eY2L3tf12uHGygLzR1kO9MPvGnW5oC9FCaKlf7jYYNl5snjFxf7
MIME-Version: 1.0
X-Received: by 10.60.173.42 with SMTP id bh10mr27981895oec.58.1448545957115; Thu, 26 Nov 2015 05:52:37 -0800 (PST)
Received: by 10.76.171.103 with HTTP; Thu, 26 Nov 2015 05:52:37 -0800 (PST)
X-Originating-IP: [148.87.19.222]
Date: Thu, 26 Nov 2015 21:52:37 +0800
Message-ID: <CAAgBOhuOPB=jxO=WWHmy_y7ARY5qfdK2x4xC9t-Z-vn0UU5Paw@mail.gmail.com>
From: Xuelei Fan <xuelei.fan@vimino.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="047d7bd6bf1c371414052571e337"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/1E1ffJopy5zY30pKPy7aZ9csWjo>
Subject: [TLS] Extensions "supported_groups" and "key_share" in TLS 1.3
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: Thu, 26 Nov 2015 13:52:39 -0000

Hi,

Per the latest draft of TLS 1.3, both "supported_groups" and "key_share"
extensions are REQUIRED for DHE or ECDHE cipher suites (Section 8.2).  Both
extension need to provide the supported named groups in preference order.
Looks like the functions are overlapped.  I was wondering, it may be nice
to obsolete the "supported_groups" extension, and use "key_share" extension
for both the supported named groups and the key exchange information for
each group.

For the "supported_groups" extension, the description is (Section 6.3.2.2):
   ---------------
   Clients which offer one or more (EC)DHE cipher suites MUST send at
   least one supported NamedGroup value and servers MUST NOT negotiate
   any of these cipher suites unless a supported value was provided.  If
   this extension is not provided and no alternative cipher suite is
   available, the server MUST close the connection with a fatal
   "missing_extension" alert.  (see Section 8.2) If the extension is
   provided, but no compatible group is offered, the server MUST NOT
   negotiate a cipher suite of the relevant type.  For instance, if a
   client supplies only ECDHE groups, the server MUST NOT negotiate
   finite field Diffie-Hellman.  If no acceptable group can be selected
   across all cipher suites, then the server MUST generate a fatal
   "handshake_failure" alert.
   ---------------

For the "key_share" extension, the description is (Section 6.3.2.3):
   ---------------
   Clients which offer one or more (EC)DHE cipher suites MUST send at
   least one supported KeyShare value and servers MUST NOT negotiate any
   of these cipher suites unless a supported value was provided.  If
   this extension is not provided in a ServerHello or retried
   ClientHello, and the peer is offering (EC)DHE cipher suites, then the
   endpoint MUST close the connection with a fatal "missing_extension"
   alert.
   ---------------

The "supported_groups" extension defines the groups, while the "key_share"
extension defines both the groups and the key exchange information.  Both
extension has its own preferences for the supported named groups.  It's
easy to get conflicted if the two preferences are not consistent.  The
"key_share" extension contains the information of the supported named
groups.  So, the information can be used to indicate the client supported
named groups.  Maybe, for TLS 1.3, it is not necessary to use the
"supported_groups" extension any more.

Cheers,
Xuelei