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

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

Thanks, Ben!

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

Regards,
Stanislav 


> On 12 Aug 2021, at 03:09, Benjamin Kaduk <[e-mail]> wrote:
> 
> 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.
>>> 
>> 
>