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

Dear Yoav, Dear Amanda,

Thank you very much for your prompt reply!

  *   The others (TBD7, TBD8, TBD9) are finite field, so they should start at 261.

Let me correct you a little here, if you don’t mind: these three are also elliptic curve ones (they are defined in RFC 4357 along with finite field ones, but these three are elliptic curves, unlike GOST R 34.10-94 parameters, which were finite field ones). So all TBD6-TBD12 should start at 34.

None of these are IETF-endorsed algorithms, so the Recommended column is ’N’.  The numbers are fine, but I believe that no specific numbers were requested, so any numbers should be OK.

{0xFF, 0x85} for TLS_GOSTR341112_256_WITH_28147_CNT_IMIT
is perfect, but another one ({0xFF, 0x83} collides with a privately used (by someone) old SSL_RSA_WITH_3DES_EDE_CBC_MD5.

So, if possible, it would be great if you could assign the following numbers, for example:

{0xFF, 0x89} to TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC,
{0xFF, 0x88} to TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC,

(and
{0xFF, 0x85} for TLS_GOSTR341112_256_WITH_28147_CNT_IMIT, as you have proposed)

Of course, “N” in “Recommended” column for all of them.

Thank you very much!

Best regards,
Stanislav

1 февр. 2019 г., в 22:50, Yoav Nir <ynir.ietf@gmail.com<mailto:ynir.ietf@gmail.com>> написал(а):

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-param@iana.org<mailto:iana-prot-param@iana.org>> wrote:

Hi Yoav,

We have questions about these registrations:

1) Do you want us to make all of the registrations in the IANA Considerations section, or is this request just referring to the TLS Cipher Suites?

[YN] - all of it

2) Which values are we assigning to the TLS Cipher Suites? Are we assigning {0xFF, 0x83} to TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC, {0xFF, 0x84} to TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC, and {0xFF, 0x85} for TLS_GOSTR341112_256_WITH_28147_CNT_IMIT ? Also, is the value of the "Recommended" column "N”?

None of these are IETF-endorsed algorithms, so the Recommended column is ’N’.  The numbers are fine, but I believe that no specific numbers were requested, so any numbers should be OK.

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?)

Yes, starting at 64 is fine.

4) For the TLS Supported Groups registrations, should we start from value 34, 261, 512, or 65283?

That’s a little complex.  Authors, please check that I am correct here:

  *   GC256A (TBD6), GC512A (TBD10), GC512B (TBD11), and GC512C (TBD12) are elliptic curve, so they should start at 34.
  *   The others (TBD7, TBD8, TBD9) are finite field, so they should start at 261.

5) Can you confirm that the TLS ClientCertificateType Identifiers registrations should start from 67, the first available value in the Specification Required range?

Sure.

The registries are here:

https://www.iana.org/assignments/tls-parameters

Best regards,

Amanda Baber
Lead IANA Services Specialist

On Fri Feb 01 18:58:12 2019, ynir.ietf@gmail.com<mailto:ynir.ietf@gmail.com> wrote:
[Adding IANA]

Hi, Stanislav

Sorry for dropping this.  Yes, we’ve considered this, and you can
definitely have the registration as described in your draft.

Yoav

https://tools.ietf.org/html/draft-smyshlyaev-tls12-gost-suites-
04#section-9 <https://tools.ietf.org/html/draft-smyshlyaev-tls12-gost-
suites-04#section-9>

On 1 Feb 2019, at 9:28, Смышляев Станислав Витальевич
<svs@cryptopro.ru<mailto:svs@cryptopro.ru>> wrote:

Dear Yoav, Rich and Nick,

Do you have any additional questions about this request? Dmitry
Belyavsky and I will be very happy to provide any clarifications, if
needed.

Best regards,
Stanislav Smyshlyaev, Ph.D.
CISO, CryptoPro LLC

From: Смышляев Станислав Витальевич <svs@cryptopro.ru<mailto:svs@cryptopro.ru>>
Sent: Wednesday, January 9, 2019 11:26 PM
To: Yoav Nir <ynir.ietf@gmail.com<mailto:ynir.ietf@gmail.com>>
Cc: Евгений Алексеев <geni-cmc@mail.ru<mailto:geni-cmc@mail.ru>>; tls-reg-review@ietf.org<mailto:tls-reg-review@ietf.org>;
Смышляева Екатерина Сергеевна <ess@cryptopro.ru<mailto:ess@cryptopro.ru>>; Коллегин Максим
Дмитриевич <kollegin@cryptopro.ru<mailto:kollegin@cryptopro.ru>>; Алексеев Евгений Константинович
<alekseev@cryptopro.ru<mailto:alekseev@cryptopro.ru>>; Белявский Дмитрий <beldmit@cryptocom.ru<mailto:beldmit@cryptocom.ru>>
Subject: Re: [Tls-reg-review] Request to register value in TLS bar
registry

CC’ing Dmitry Belyavsky (in case he would like to add some other
clarifications), who we discussed the IANA request for the GOST
cipher suites with (in Bangkok).

Best regards,
Stanislav Smyshlyaev

9 янв. 2019 г., в 22:52, Смышляев Станислав Витальевич
<svs@cryptopro.ru<mailto:svs@cryptopro.ru> <mailto:svs@cryptopro.ru>> написал(а):

Dear Yoav,

Thank you very much for your comments!
If you don’t mind, I’ll reply:
1) Yes, Kuznyechik is the new Russian cipher. It is defined in RFC
7801.
2) There’s still work in progress on an AEAD mode to be standardized
in Russia - and we can’t have a TLS 1.3 cipher suite without an AEAD
mode. Currently the MGM mode (see https://tools.ietf.org/html/draft-
smyshlyaev-mgm-09 <https://tools.ietf.org/html/draft-smyshlyaev-mgm-
09>) is being carefully studied and tends to be the one. Valery
Smyslov waits for it also - to be able to work on IKEv2 and ESP with
GOSTs.
That’s why the current request (and the draft it refers to) is only
about TLS 1.2 so far.
3) Unfortunately, there is a misleading statement in the current
version of the draft (thank you for pointing to it, Yoav!): actually,
{0x00, 0x81} is used for the older cipher suite from
https://tools.ietf.org/html/draft-chudov-cryptopro-cptls-04#section-5
<https://tools.ietf.org/html/draft-chudov-cryptopro-cptls-04#section-
5>. The existing implementations of
TLS_GOSTR341112_256_WITH_28147_CNT_IMIT use the number {0xFF, 0x85}

Best regards,
Stanislav Smyshlyaev

9 янв. 2019 г., в 21:39, Yoav Nir <ynir.ietf@gmail.com<mailto:ynir.ietf@gmail.com>
<mailto:ynir.ietf@gmail.com>> написал(а):

Hi, Evgeny.

We’ll give the answer in a few days. First, I’d like to ask a few
clarifying questions:
If I understand correctly, the Kuznyechik ciphers in this document is
the new GOST algorithms, right?
I have noticed that this is only for TLS 1.2.  Why not TLS 1.3?
Section 10 mentions that there are existing implementations that use
the value {0x00,0x81} for TLS_GOSTR341112_256_WITH_28147_CNT_IMIT.  I
see in the IANA registry <https://www.iana.org/assignments/tls-
parameters/tls-parameters.xml#tls-parameters-4> that this value is
free.  Do you want to re-use it?

Thanks

Yoav

On 9 Jan 2019, at 15:16, Евгений Алексеев <geni-
cmc=40mail.ru@dmarc.ietf.org<mailto:cmc=40mail.ru@dmarc.ietf.org> <mailto:geni-
cmc=40mail.ru@dmarc.ietf.org<mailto:cmc=40mail.ru@dmarc.ietf.org>>> wrote:

Hello!

We would like to ask IANA to assign numbers in accordance with the
IANA Considerations section of the "GOST Cipher Suites for Transport
Layer Security (TLS) Protocol Version 1.2" document
(https://tools.ietf.org/html/draft-smyshlyaev-tls12-gost-suites-
04#section-9 <https://tools.ietf.org/html/draft-smyshlyaev-tls12-
gost-suites-04#section-9>).

--
Best regards,
Evgeny Alekseev
_______________________________________________
tls-reg-review mailing list
tls-reg-review@ietf.org<mailto:tls-reg-review@ietf.org> <mailto:tls-reg-review@ietf.org>
https://www.ietf.org/mailman/listinfo/tls-reg-review
<https://www.ietf.org/mailman/listinfo/tls-reg-review>