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

[Смышляев Станислав Вита льевич <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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.
>>> 
> 
>