[TLS] Inconsistent extension definitions

Yishuai Li <yishuai@upenn.edu> Mon, 24 June 2019 02:48 UTC

Return-Path: <yishuai@upenn.edu>
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 2FB7B1202C0 for <tls@ietfa.amsl.com>; Sun, 23 Jun 2019 19:48:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.273
X-Spam-Level:
X-Spam-Status: No, score=0.273 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.972] autolearn=no autolearn_force=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 WpG1G2A2yYwY for <tls@ietfa.amsl.com>; Sun, 23 Jun 2019 19:48:56 -0700 (PDT)
Received: from mx0b-000c2a01.pphosted.com (mx0b-000c2a01.pphosted.com [148.163.155.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A753F1202CE for <tls@ietf.org>; Sun, 23 Jun 2019 19:48:55 -0700 (PDT)
Received: from pps.filterd (m0128480.ppops.net [127.0.0.1]) by mx0b-000c2a01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x5O2i5oR014409 for <tls@ietf.org>; Sun, 23 Jun 2019 22:48:54 -0400
Received: from hound.seas.upenn.edu (coyote.seas.upenn.edu [158.130.71.130]) by mx0b-000c2a01.pphosted.com with ESMTP id 2t9j0f3tkf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <tls@ietf.org>; Sun, 23 Jun 2019 22:48:54 -0400
Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) (authenticated bits=0) by hound.seas.upenn.edu (8.15.2/8.15.2) with ESMTPSA id x5O2mrOx027000 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for <tls@ietf.org>; Sun, 23 Jun 2019 22:48:54 -0400
Received: by mail-io1-f42.google.com with SMTP id w25so711290ioc.8 for <tls@ietf.org>; Sun, 23 Jun 2019 19:48:54 -0700 (PDT)
X-Gm-Message-State: APjAAAUXz0ZW76TSE+3JLfRDKVKDHpRSt9fhzostHmjoU2e1gUwirhk0 9lzBe/SUS3K8EhUojkbdhed4U/zCulGvwtjuw2HN
X-Google-Smtp-Source: APXvYqwT6V+eFKJwlP4U/6Hg18FaeNLukyqyqs9x24GI205/u4H/6JnAhd6lYCEmo0docZL8m5Y86oIlwU9pEBeMXk8=
X-Received: by 2002:a05:6638:29a:: with SMTP id c26mr18127187jaq.98.1561344528623; Sun, 23 Jun 2019 19:48:48 -0700 (PDT)
MIME-Version: 1.0
From: Yishuai Li <yishuai@upenn.edu>
Date: Sun, 23 Jun 2019 22:48:05 -0400
X-Gmail-Original-Message-ID: <CABCqrhJ-SiahCEED2A6bX3h5KbR2GTAnqcPkz+YvwB30mFHCHQ@mail.gmail.com>
Message-ID: <CABCqrhJ-SiahCEED2A6bX3h5KbR2GTAnqcPkz+YvwB30mFHCHQ@mail.gmail.com>
To: tls@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.46,1.0.8 definitions=2019-06-24_02:2019-06-22,2019-06-24 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 clxscore=1011 phishscore=0 mlxlogscore=999 mlxscore=0 bulkscore=0 adultscore=0 malwarescore=0 suspectscore=3 impostorscore=0 lowpriorityscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1904300001 definitions=main-1906240021
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/onPVTtYUGrI3kv9nV7wRUU_GQss>
Subject: [TLS] Inconsistent extension definitions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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, 24 Jun 2019 02:51:24 -0000

Dear TLS working group,

Here’s a duplicate of GitHub issue tlswg/tls13-rfc#21 I opened today,
which somehow disappeared:

Supported Versions are defined as Variants:

    struct {
        select (Handshake.msg_type) {
            case client_hello:
                 ProtocolVersion versions<2..254>;

            case server_hello: /* and HelloRetryRequest */
                 ProtocolVersion selected_version;
        };
    } SupportedVersions;

while Key Share is defined as separate Constructed Types:

    struct {
        KeyShareEntry client_shares<0..2^16-1>;
    } KeyShareClientHello;

    struct {
        NamedGroup selected_group;
    } KeyShareHelloRetryRequest;

    struct {
        KeyShareEntry server_share;
    } KeyShareServerHello;

Is there a specific reason for choosing different definition styles?
Is it worth unifying them?

Also, is this mailing list the right place for such questions?

Thanks,
Yishuai Li