Subject: Re: [Tls-reg-review] [IANA #1135278] Re: Request to register value in TLS bar registry (tls-parameters)

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 6 Aug 2021 14:51:22 -0700

Sorry to dig up an old thread...

On Fri, Feb 01, 2019 at 09:50:41PM +0200, Yoav Nir wrote:
> Hi, Amanda.  Inline.
> 
> Authors: please check my answers, especially about the supported groups.
> 
> > On 1 Feb 2019, at 21:32, Amanda Baber via RT <[email-masked]> wrote:
> 
> > 3) For the TLS SignatureAlgorithm registrations, can you confirm that we should  start from value 64, the beginning of the Specification Required range? (Also because the values are marked "Reserved" rather than "Unassigned," is it possible to make registrations here without an approved document? Is "Reserved," which in RFC 8126 means "unavailable for assignment," meant to indicate availability here, as it sometimes did for older registries?)

No, "Reserved" does not indicate availability here.

The SignatureAlgorithm registry is nominally closed, having been superseded
by the SignatureScheme registry that effectively combines the
SignatureAlgorithm and HashAlgorithm registries and is conveyed in the same
protocol field.

https://datatracker.ietf.org/doc/html/rfc8447#section-15 is perhaps not as
clear about this as it could be, but the intent was to not make additional
allocations from this registry.

I think we need to convert these allocations into a handful of
corresponding entries in the SignatureScheme registry, to avoid burning a
sizeable chunk of the remaining SignatureScheme codepoint space.
Fortunately, they seem to only be paired with the 0x08 "intrinsic" hash
algorithm, which would help reduce the number of allocations needed in the
SignatureScheme registry.

-Ben

> Yes, starting at 64 is fine.
>

---

From: Смышляев Станислав Витальевич <[email-masked]>
Date: Sat, 7 Aug 2021 07:48:23 +0000

Hi Ben,

Thank you so much for your careful and detailed review (the other authors and I will reply to it in a separate message later in the corresponding Conflict Review thread- I agree with most of your comments)!

Regarding the IANA considerations of the draft-smyshlyaev-tls12-gost-suites document:
1) Those two early allocations for these two SignatureAlgorithms were made two and a half years ago (much earlier than RFC 8447) and are now currently widely used in many implementations in Russia (gostr34102012_256 and gostr34102012_512 are the only signature algorithms used in Russia, they are standardized in ISO/IEC 14888-3). Ben, could you please help us with finding an easy way of solving this issue together (without a specific Standards Track document just for two allocations)?..
2) The four other ciphersuites you asked about (0xC1, 0x03 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L etc.) list another draft as their reference, https://datatracker.ietf.org/doc/draft-smyshlyaev-tls13-gost-suites/ (the only difference in the name is "tls13" instead of "tls12").

Best regards,
Stanislav Smyshlyaev, Ph.D.
Deputy CEO, CryptoPro LLC

-----Original Message-----
From: Benjamin Kaduk <[email-masked]> 
Sent: Saturday, August 7, 2021 12:51 AM
To: Yoav Nir <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Коллегин Максим <[email-masked]>; Алексеев Евгений Константинович <[email-masked]>; Смышляев Станислав Витальевич <[email-masked]>; Смышляева Екатерина Сергеевна <[email-masked]>; Белявский Дмитрий <[email-masked]>
Subject: Re: [Tls-reg-review] [IANA #1135278] Re: Request to register value in TLS bar registry (tls-parameters)

On Fri, Feb 01, 2019 at 09:50:41PM +0200, Yoav Nir wrote:
> > 3) For the TLS SignatureAlgorithm registrations, can you confirm 
> > that we should  start from value 64, the beginning of the 
> > Specification Required range? (Also because the values are marked 
> > "Reserved" rather than "Unassigned," is it possible to make 
> > registrations here without an approved document? Is "Reserved," 
> > which in RFC 8126 means "unavailable for assignment," meant to 
> > indicate availability here, as it sometimes did for older 
> > registries?)

The SignatureAlgorithm registry is nominally closed, having been superseded by the SignatureScheme registry that effectively combines the SignatureAlgorithm and HashAlgorithm registries and is conveyed in the same protocol field.

https://datatracker.ietf.org/doc/html/rfc8447#section-15 is perhaps not as clear about this as it could be, but the intent was to not make additional allocations from this registry.

I think we need to convert these allocations into a handful of corresponding entries in the SignatureScheme registry, to avoid burning a sizeable chunk of the remaining SignatureScheme codepoint space.
Fortunately, they seem to only be paired with the 0x08 "intrinsic" hash algorithm, which would help reduce the number of allocations needed in the SignatureScheme registry.

-Ben

---

From: "Michelle Cotton via RT" <[email-masked]>
Date: Tue, 10 Aug 2021 16:50:13 +0000

Ben and Stanislav,

Will there be any changes required to these registrations at this time?

Or can we resolve this ticket?

Thanks in advance.

--Michelle

Michelle Cotton
Protocol Parameters Engagement Sr. Manager
IANA Services

On Sat Aug 07 07:48:52 2021, [email-masked] wrote:
> Hi Ben,
> 
> Thank you so much for your careful and detailed review (the other
> authors and I will reply to it in a separate message later in the
> corresponding Conflict Review thread- I agree with most of your
> comments)!
> 
> 1) Those two early allocations for these two SignatureAlgorithms were
> made two and a half years ago (much earlier than RFC 8447) and are now
> currently widely used in many implementations in Russia
> (gostr34102012_256 and gostr34102012_512 are the only signature
> algorithms used in Russia, they are standardized in ISO/IEC 14888-3).
> Ben, could you please help us with finding an easy way of solving this
> issue together (without a specific Standards Track document just for
> two allocations)?..
> 2) The four other ciphersuites you asked about (0xC1, 0x03
> TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L etc.) list another draft as
> their reference, https://datatracker.ietf.org/doc/draft-smyshlyaev-
> tls13-gost-suites/ (the only difference in the name is "tls13" instead
> of "tls12").
> 
> Best regards,
> Cc: [email-masked]; [email-masked]; geni-
> [email-masked]; Коллегин Максим <[email-masked]>; Алексеев Евгений
> Константинович <[email-masked]>; Смышляев Станислав Витальевич
> <[email-masked]>; Смышляева Екатерина Сергеевна <[email-masked]>;
> Белявский Дмитрий <[email-masked]>
> Subject: Re: [Tls-reg-review] [IANA #1135278] Re: Request to register
> value in TLS bar registry (tls-parameters)
> 
> The SignatureAlgorithm registry is nominally closed, having been
> superseded by the SignatureScheme registry that effectively combines
> the SignatureAlgorithm and HashAlgorithm registries and is conveyed in
> the same protocol field.
> 
> https://datatracker.ietf.org/doc/html/rfc8447#section-15 is perhaps
> not as clear about this as it could be, but the intent was to not make
> additional allocations from this registry.
> 
> corresponding entries in the SignatureScheme registry, to avoid
> burning a sizeable chunk of the remaining SignatureScheme codepoint
> space.
> Fortunately, they seem to only be paired with the 0x08 "intrinsic"
> hash algorithm, which would help reduce the number of allocations
> needed in the SignatureScheme registry.
> 
> -Ben
>

---

From: Смышляев Станислав Витальевич <[email-masked]>
Date: Tue, 10 Aug 2021 17:22:25 +0000

Dear Michelle, 

We’ve started the discussion in a separate thread dedicated to the conflict review (together with Adrian Farrel). 

Of course I would strongly prefer (and ask) that no changes are made at this time, since these identifiers (allocated more than 2.5 years ago) are widely used in many implementations. 

Kind regards,
Stanislav 

> On 10 Aug 2021, at 19:50, Michelle Cotton via RT <[email-masked]> wrote:
> 
> Ben and Stanislav,
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 11 Aug 2021 17:09:45 -0700

Hi Stanislav,

Sorry for the slow reply; my scheduling estimates for this week's work were
off by quite a bit.

> 1) Those two early allocations for these two SignatureAlgorithms were made two and a half years ago (much earlier than RFC 8447) and are now currently widely used in many implementations in Russia…

I started a new thread and tried to write up my thoughts+proposal there:
https://mailarchive.ietf.org/arch/msg/tls-reg-review/1RJOKg9Cnt1PHS-iOC5sOOt5aeE/
.  It does hinge on the gostr34102012_256 and gostr34102012_512 values only
being in current use when combined with the HashAlgorithm value 8
("intrinsic"), though, which I don't have any real data about.

> 2) The four other ciphersuites you asked about (0xC1, 0x03 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L etc.) list another draft as their reference, https://datatracker.ietf.org/doc/draft-smyshlyaev-t…

Oops, sorry for missing that.  Thanks for the clarification, and glad to
hear that there is no problem here!

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 11 Aug 2021 17:12:59 -0700

Hi Michelle,

> Or can we resolve this ticket?

The question of whether or not changes will be made is still open; I
started a thread at
https://mailarchive.ietf.org/arch/msg/tls-reg-review/1RJOKg9Cnt1PHS-iOC5sOOt5aeE/
to try and make progress on that question.

>From a ticketing system point of view, can you leave the ticket open and
point to that thread on tls-reg-review to track its resolution?

-Ben

---

From: Смышляев Станислав Витальевич <[email-masked]>
Date: Thu, 12 Aug 2021 04:27:11 +0000

Thanks, Ben!

Let’s continue this discussion in that separate thread you started. 

Regards,
Stanislav 

> On 12 Aug 2021, at 03:09, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi Stanislav,
>