[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
- [TLS] Inconsistent extension definitions Yishuai Li
- Re: [TLS] Inconsistent extension definitions Eric Rescorla