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

[Benjamin Kaduk <[e-mail]>]

Hi Stanislav,

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

On Sat, Aug 07, 2021 at 07:48:23AM +0000, Смышляев Станислав Витальевич 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)!
> 
> 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)?..

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-tls13-gost-suites/ (the only difference in the name is "tls13" instead of "tls12").

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

-Ben

> Best regards,
> Stanislav Smyshlyaev, Ph.D.
> Deputy CEO, CryptoPro LLC
> 
> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]> 
> Sent: Saturday, August 7, 2021 12:51 AM
> To: Yoav Nir <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; Коллегин Максим <[e-mail]>; Алексеев Евгений Константинович <[e-mail]>; Смышляев Станислав Витальевич <[e-mail]>; Смышляева Екатерина Сергеевна <[e-mail]>; Белявский Дмитрий <[e-mail]>
> Subject: Re: [Tls-reg-review] [IANA #1135278] Re: Request to register value in TLS bar registry (tls-parameters)
> 
> 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 <[e-mail]> 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.
> > 
>