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

From: "Short, Todd" <[email-masked]>
Date: Wed, 5 Jul 2017 17:05:21 +0000

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
// [email-masked]<mailto:[email-masked]>
// "One if by land, two if by sea, three if by the Internet."

---

From: David Benjamin <[email-masked]>
Date: Wed, 05 Jul 2017 17:22:23 +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 <[email-masked]> wrote:

> 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:
>
>    [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.
> 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
> // [email-masked]
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Short, Todd" <[email-masked]>
Date: Wed, 5 Jul 2017 17:45:04 +0000

But the maximum value doesn’t have to be listed twice if it’s already part of a value.

So section 11 needs to change...
--
-Todd Short
// [email-masked]<mailto:[email-masked]>
// "One if by land, two if by sea, three if by the Internet."

On Jul 5, 2017, at 1:22 PM, David Benjamin <[email-masked]<mailto:[email-masked]>> wrote:

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 <[email-masked]<mailto:[email-masked]>> wrote:
In section 4.2.3 the definitions oaf the signature scheme are thus:

enum {

    ...

} SignatureScheme;

-  TLS SignatureScheme Registry: Values with the first byte in the
   range 0-254 (decimal) are assigned via Specification Required
   [RFC5226<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5226&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=l109_N0_O2jfQhrTMmDXBVcEfjnnS_cNjtZ-QUzNtTY&s=5sk_b3-vIekmFErj0rRi5Gpm-jPXdqdlgGI7xYAILh4&e=>].  Values with the first byte 255 (decimal) are reserved
   for Private Use [RFC5226<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5226&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=l109_N0_O2jfQhrTMmDXBVcEfjnnS_cNjtZ-QUzNtTY&s=5sk_b3-vIekmFErj0rRi5Gpm-jPXdqdlgGI7xYAILh4&e=>].

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=l109_N0_O2jfQhrTMmDXBVcEfjnnS_cNjtZ-QUzNtTY&s=EAWqDhMCo32S6c4de6RPEdpj7p-tif1Wz-ZbwHQRRaY&e=>

---

From: David Benjamin <[email-masked]>
Date: Wed, 05 Jul 2017 17:53:36 +0000

> But the maximum value doesn’t have to be listed twice if it’s already part

Ah yes, you're right. My bad. I agree that line should not be there either.

> On Jul 5, 2017, at 1:22 PM, David Benjamin <[email-masked]> wrote:
>
>> 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:
>>
>>    [RFC5226 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5226&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=l109_N0_O2jfQhrTMmDXBVcEfjnnS_cNjtZ-QUzNtTY&s=5sk_b3-vIekmFErj0rRi5Gpm-jPXdqdlgGI7xYAILh4&e=>].  Values with the first byte 255 (decimal) are reserved
>>    for Private Use [RFC5226 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5226&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=l109_N0_O2jfQhrTMmDXBVcEfjnnS_cNjtZ-QUzNtTY&s=5sk_b3-vIekmFErj0rRi5Gpm-jPXdqdlgGI7xYAILh4&e=>].
>>
>>
>> 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
>> // [email-masked]
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=l109_N0_O2jfQhrTMmDXBVcEfjnnS_cNjtZ-QUzNtTY&s=EAWqDhMCo32S6c4de6RPEdpj7p-tif1Wz-ZbwHQRRaY&e=>
>>
>
>

---

From: "Short, Todd" <[email-masked]>
Date: Wed, 5 Jul 2017 17:55:22 +0000

That wasn’t important enough for to create a PR.

I did create PR 1044 to reconcile S4.2.3 and S11.

From: David Benjamin <[email-masked]>
Date: Wednesday, July 5, 2017 at 1:53 PM
To: "Short, Todd" <[email-masked]>
Cc: "<[email-masked]>" <[email-masked]>
Subject: Re: [TLS] draft-ietf-tls-tls13-21: Signature algorithms definition discrepancy

On Wed, Jul 5, 2017 at 1:46 PM Short, Todd <[email-masked]<mailto:[email-masked]>> wrote:
But the maximum value doesn’t have to be listed twice if it’s already part of a value.

enum {

    ...

    (0xFFFF)

} SignatureScheme;