Re: [TLS] draft-ietf-tls-tls13-21: Signature algorithms definition discrepancy

David Benjamin <davidben@chromium.org> Wed, 05 July 2017 17:22 UTC

Return-Path: <davidben@google.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 78B37131D94 for <tls@ietfa.amsl.com>; Wed, 5 Jul 2017 10:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 4H2IQI6T8AJW for <tls@ietfa.amsl.com>; Wed, 5 Jul 2017 10:22:36 -0700 (PDT)
Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::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 7CEAD131D93 for <tls@ietf.org>; Wed, 5 Jul 2017 10:22:35 -0700 (PDT)
Received: by mail-pg0-x233.google.com with SMTP id t186so128059664pgb.1 for <tls@ietf.org>; Wed, 05 Jul 2017 10:22:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=N+Fn8q+C1uTiV13Z27GXaP97yyFPAPtYDTXFPaFdRoI=; b=j+OCl4/sf3OgSouN7ujlL7eKii98Uo3tcXP4U/BAOuNtWwfbTtA5IYC4yhg5/KWo/C K675Hhw4U8uH9LoAAK6cIGgfd7EMYP13ifG2XdJULSSzd20ro5lT9AiuhcWtSyFGUzgk PhOEPIZ9iSkCNkB+kTL30MC67eUOvBT8uYgv4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=N+Fn8q+C1uTiV13Z27GXaP97yyFPAPtYDTXFPaFdRoI=; b=Q8vXl8bDHHdJdHpxRvcw8FgzEsMk4uNLEnTqpsApyEp5cJ7Fylnm1cPsGUfKO9dthR Kxy8h1ib6c5lu6oJcdFSvAEYOOVJ35PNZ7AX5T7hrNpGh+D1nevHKfxLVGv/7064mhGl CwRTd+hxV/rFn2mIRBFtDr5kkiIu0ujAZs57T5ghTo6dyXrRbSQ0C8DBkou8W/yybb8V y9WfC9TpIqDJtxJ9rE+dgv+MlhMivRe0idM2y0WyWNhCjf0ZUuM16LTSkUbUBTft8rOQ 5DfZHMbD+k8J159EEwB3RYwVf41UIdwopf/4lk4PtELR73FmjXauLjNmyADiI/MD2VeQ ROQw==
X-Gm-Message-State: AIVw110WUImB2bhFTvT1Sy4eOAq3yNp4ArwsiDM89jo6QLCUzi44k7cJ 25H+6xPANsTZF2Fd0AVuNFWawqZMnvqW
X-Received: by 10.101.70.137 with SMTP id h9mr22258852pgr.50.1499275354947; Wed, 05 Jul 2017 10:22:34 -0700 (PDT)
MIME-Version: 1.0
References: <B57C3372-71DF-4A4E-AE80-DAEB308C6EB7@akamai.com>
In-Reply-To: <B57C3372-71DF-4A4E-AE80-DAEB308C6EB7@akamai.com>
From: David Benjamin <davidben@chromium.org>
Date: Wed, 05 Jul 2017 17:22:23 +0000
Message-ID: <CAF8qwaB2norEb+Bfj6hAXLs+afEUnFwnTH_oSJkNwV4z+KvzCA@mail.gmail.com>
To: "Short, Todd" <tshort@akamai.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="089e08237174f44b140553953e71"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/p5Ff2DEnSxSyDllyQZAid-zG9Sc>
Subject: Re: [TLS] draft-ietf-tls-tls13-21: Signature algorithms definition discrepancy
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 05 Jul 2017 17:22:38 -0000

0xFFFF is just the syntax for the maximum value in the enum.

The intent was to match the HashAlgorithm registry which makes 0xFE and
0xFF the private use values, so I would say the enum is correct and the
IANA considerations text is wrong. This ensures we don't collide with any
existing TLS 1.2 private use allocations.

On Wed, Jul 5, 2017 at 1:05 PM Short, Todd <tshort@akamai.com> wrote:

> In section 4.2.3 the definitions oaf the signature scheme are thus:
>
> enum {
>
>     ...
>     /* Reserved Code Points */
>     private_use(0xFE00..0xFFFF),
>     (0xFFFF)
>
> } SignatureScheme;
>
>
> This indicates that if the first byte is 254 (0xFE) or 255 (0xFF), that is
> is for private use. However, in section 11, a new registry is defined for
> signature schemes:
>
> -  TLS SignatureScheme Registry: Values with the first byte in the
>    range 0-254 (decimal) are assigned via Specification Required
>    [RFC5226 <https://tools.ietf.org/html/rfc5226>].  Values with the first byte 255 (decimal) are reserved
>    for Private Use [RFC5226 <https://tools.ietf.org/html/rfc5226>].
>
>
> Indicates that values with the first byte of 254 are reserved/assigned,
> and that private use is for values with a first byte of 255.
> In addition, the value of 0xFFFF is listed twice in the SignatureScheme
> enumeration.
>
> I can do a PR, but it needs to be decided wether 0xFE is reserved/assigned
> or private_use, and whether 0xFFFF has any special value.
>
> --
> -Todd Short
> // tshort@akamai.com
> // "One if by land, two if by sea, three if by the Internet."
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>