[TLS] PR #604 Change "supported_groups" to "supported_kems"

Zhenfei Zhang <zzhang@securityinnovation.com> Mon, 29 August 2016 20:00 UTC

Return-Path: <zzhang@securityinnovation.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE2412D870 for <tls@ietfa.amsl.com>; Mon, 29 Aug 2016 13:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=securityinnovation.com
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 gmC4TPW9one3 for <tls@ietfa.amsl.com>; Mon, 29 Aug 2016 13:00:33 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 C1DB212B032 for <tls@ietf.org>; Mon, 29 Aug 2016 12:52:51 -0700 (PDT)
Received: by mail-oi0-x233.google.com with SMTP id c15so211084236oig.0 for <tls@ietf.org>; Mon, 29 Aug 2016 12:52:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securityinnovation.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=MsCbORbVun0gUbRLH7oQ/yJ5pP9M9XvXa9SUX6jor1U=; b=SGE00v4GjkUiSu+mX4ol5d5GHzvfZD2zKJig+LPS0kpKM2tG+oRvYnyM7Sjxm5Udtd Ekq9ZBc8L/I5zI12IlYNCWubzSbNvNdpWFYgrqVgkwU6WaxaqMEWBer8FkRO+F2wvnVv TxuCG7exBSLbsNx/FEdvRICOd+bs7QsktenvU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MsCbORbVun0gUbRLH7oQ/yJ5pP9M9XvXa9SUX6jor1U=; b=SEOUY8YdZeGfUPVMb52i8Bo4HtrFPoaIGHZNFFRRv5TKHIttFDm8U8+wQu6G3KL9+e EbUO3ahUOgWpWmfjh6Pug6ocwyC8mnsXrjiunWF8pr3M0m5jrUhRW2TsDFwKw9WokByR ud+1zm6MY5UVd1mR1NPATL3mR3QRbX5NPB/gm2T4Dfc089irzG0UiB2/vKsAW9pN6mbu yVz8tTWln1a4NtZocPCYi10mzYv+F4z9IRQ8xjg+VO2568B1Zuww1YjoybMSK/sj3s2U 5LKLaghW7muVVbfxYV/O6zophDivJSX7bGA46USCy6+51xMv+hyYY8L4KKGHWYSN7Nzy mnkw==
X-Gm-Message-State: AE9vXwNv2r85PbJqYOVUgO4GZ9flVudKWA6Wh0hS+uivXuSf8j1/jsYBy63bYRuleQpUQCRIVA/bRdzbcwATtLAc
X-Received: by 10.202.205.77 with SMTP id d74mr12615843oig.63.1472500370898; Mon, 29 Aug 2016 12:52:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.70.71 with HTTP; Mon, 29 Aug 2016 12:52:50 -0700 (PDT)
From: Zhenfei Zhang <zzhang@securityinnovation.com>
Date: Mon, 29 Aug 2016 15:52:50 -0400
Message-ID: <CAB20dTt23w5oJX+i7kM1g5db=q33Af+51AH5Z0xnnptpyX90jw@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary=001a11476fac8a181b053b3b35ab
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/AnSksztK1vSaWB1Fzqdph0hryxw>
Subject: [TLS] PR #604 Change "supported_groups" to "supported_kems"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 29 Aug 2016 20:00:36 -0000

Hi list,


I have created a pull request

https://github.com/tlswg/tls13-spec/pull/604


I would like to suggest that we change the terminology "NamedGroup" to
"KeyExchangeMethod".


In [1], it is suggested that we redefine the syntax, which leads to the
separation of public key crypto

and symmetric crypto during a handshake. Because of this separation, new
terminology was defined

for key exchange algorithms and authentication algorithms for public key
crypto in the key exchange

extension. "NamedGroup" was used to refer the underlying key exchange
parameters, which comes

from the "Supported Elliptic Curves" in previous versions.


The use of "NamedGroup" implicitly requests the key exchange algorithm to
be Deffie-Hellman type.

While it is safe for now, it would be nice to have some crypto agility, and
future proof. It would make

the transition to other key exchange primitives (such as lattice based key
exchange) or methods

(such as key encapsulation mechanism) easier in the future, if we do not
restrict the key exchange

by certain "Group".


Knowing that NIST has planned to standardize quantum-safe cryptography
within 7 years of time

(which can and should be accelerated), and those algorithms cannot be
described in terms of "group",

the current terminology will due for a redesign by then. So I would suggest
to change the

"NamedGroup" now rather than later.


Overall, this will have the following impact


1. HelloRetryRequest


Change HelloRetryRequest structure to


struct {

ProtocolVersion server_version;

KeyExchangeMethod selected_kem;

Extension extensions<0..2^16-1>;

} HelloRetryRequest;


2. Negotiated Groups


Throughout, change "supported_groups" to "supported_kems"; change
"NamedGroupList" to
"KeyExchangeMethodList"; change "named_group_list" to "kem_list"; change
NamedGroup to

KeyExchangeMethod


3. Key Share:

Change KeyShareEntry structure to


struct {

KeyExchangeMethod kem;

opaque key_exchange<1..2^16-1>;

} KeyShareEntry;

[1]
https://github.com/ekr/tls13-spec/blob/15126cf5a08c445aeed97c0c25c4f10c2c1b8f26/draft-ietf-tls-tls13.md


Thanks for your time.


Zhenfei Zhang