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

[Michelle Cotton via RT <[e-mail]>]

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, [e-mail] 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)?..
> 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 <[e-mail]>
> Sent: Saturday, August 7, 2021 12:51 AM
> To: Yoav Nir <[e-mail]>
> Cc: [e-mail]; [e-mail]; geni-
> [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 <iana-prot-
> > > [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.
> >