Re: [Tls-reg-review] [IANA #1272675] Request for Assignment (tls-parameters - draft-kwiatkowski-tls-ecdhe-kyber)

[Nick Sullivan <[e-mail]>]

Yes this works. Thanks for updating, Kris.

Nick

> On May 18, 2023, at 9:40 PM, Amanda Baber via RT <[e-mail]> wrote:
> 
> Hi Nick,
> 
> Can you confirm that this works? If so, we'll assign 0x639A.
> 
> thanks,
> Amanda
> 
>> On Thu May 18 19:24:31 2023, [e-mail] wrote:
>> Hi,
>> 
>> I've just aligned the draft with to the comments received.
>> https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-kyber/01/
>> 
>> I hope that is acceptable now, otherwise please let me know if you
>> have any
>> further comments.
>> 
>> Kind regards,
>> Kris
>> 
>>> On 18/05/2023 15:43, Nick Sullivan wrote:
>>> Hi All,
>>> 
>>> I have some thoughts about this allocation. We risk getting into a
>>> bit of a
>>> messy state if this hybrid kex numbering continues along this path.
>>> The
>>> existing number we have for X25519Kyber768Draft00 is 0x6399 and this
>>> request
>>> is for 0x6400, leaving a significant gap. For other sections of this
>>> registry, we've made some explicit choices (such as ffdh starting
>>> with 0x01
>>> and elliptic curves starting with 0x00). This could be a useful idea
>>> to
>>> leverage to keep the registry clean when the final hybrid kex's are
>>> decided on.
>>> 
>>> It may be more elegant to renumber these codepoints such that both
>>> octets
>>> convey meaning about the cipher used. For example,
>>> 0x63 could indicate that Kyber768 is used, and the second octet could
>>> identify the elliptic curve.
>>> In this case, X25519Kyber768Draft00 would be 0x631D and the new draft
>>> 0x6417.
>>> 
>>> On the other hand, with Kyber versions being upgradable, this may
>>> prove less
>>> than ideal if there are more iterations of Kyber. As these codepoints
>>> currently being used for experimentation, it may just be preferable
>>> to keep
>>> them in a strict ordering as they are requested.
>>> 
>>> My recommendation is therefore to use *0x639A*, the next available
>>> reserved
>>> field, for this allocation.
>>> 
>>> 
>>> Another note: the name for this codepoint is secp256r1_kyber768_d00
>>> (underscore case), while the previously allocated point
>>> is X25519Kyber768Draft00 (snake case). This should likely be
>>> consistent.
>>> 
>>> Nick
>>> 
>>> On Thu, May 18, 2023 at 10:19 AM Salz, Rich
>>> <rsalz=[e-mail]> wrote:
>>> 
>>> Me too.
>>> 
>>> On 5/18/23, 9:53 AM, "Yoav Nir" <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>> 
>>> 
>>> Seems fine. I approve
>>> 
>>> 
>>> Yoav
>>> 
>>> 
>>>> On 18 May 2023, at 3:14, Amanda Baber via RT
>>> <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>>> 
>>>> Hi Rich, Yoav, Nick (cc: Kris),
>>>> 
>>>> Can you review this new TLS Supported Groups request for us by
>>>> the 31st?
>>>> 
>>>> thanks,
>>>> Amanda
>>>> 
>>>>> Contact Name:
>>>>> Kris Kwiatkowski
>>>>> 
>>>>> Contact Email:
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> 
>>>>> Type of Assignment:
>>>>> Transport Layer Security (TLS) Parameters
>>>>> 
>>>>> 
>>>>> Registry:
>>>>> TLS Supported Groups
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Description:
>>>>> Following registration of TLS v1.3 codepoint for Post-Quantum
>>>>> hybrid
>>> key exchange composed of X25519+Kyber768 (codepoint 25497), we would
>>> like to request another TLS v1.3 codepoint for ECDHE/P256+Kyber768.
>>> The
>>> code point will make it easier to:
>>>>> * Experiment with flows in which FIPS-approved curves are used
>>>>> * Reuse in experimentation, the HW-based implementation of
>>>>> ECDH/P-256
>>> on resource constrained devices
>>>>> 
>>>>> The post-quantum, hybrid key agreement for TLS v1.3, that we
>>>>> refer
>>> to, is described in IETF draft:
>>>>> 
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-
>>> ietf-tls-hybrid-design/__;!!GjvTz_vk!R1N5_LR5owtUtnBawvy-
>>> JIRAAWeUE12VjgaFSfvFjzvac7dSxsA8MnlCFtPmBZkd0YFCU3o-WnS95QY$
>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-
>>> ietf-tls-hybrid-design/__;!!GjvTz_vk!R1N5_LR5owtUtnBawvy-
>>> JIRAAWeUE12VjgaFSfvFjzvac7dSxsA8MnlCFtPmBZkd0YFCU3o-WnS95QY$>
>>> 
>>>>> 
>>>>> Additional Info:
>>>>> We have created IETF draft that provides details on
>>>>> construction that
>>> will use the codepoint.
>>>>> 
>>> https://urldefense.com/v3/__https://www.ietf.org/id/draft-
>>> kwiatkowski-tls-ecdhe-kyber-00.html__;!!GjvTz_vk!R1N5_LR5owtUtnBawvy-
>>> JIRAAWeUE12VjgaFSfvFjzvac7dSxsA8MnlCFtPmBZkd0YFCU3o-XdcXBYA$
>>> <https://urldefense.com/v3/__https://www.ietf.org/id/draft-
>>> kwiatkowski-tls-ecdhe-kyber-00.html__;!!GjvTz_vk!R1N5_LR5owtUtnBawvy-
>>> JIRAAWeUE12VjgaFSfvFjzvac7dSxsA8MnlCFtPmBZkd0YFCU3o-XdcXBYA$>
>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> tls-reg-review mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> 
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls-
>>> reg-review__;!!GjvTz_vk!R1N5_LR5owtUtnBawvy-
>>> JIRAAWeUE12VjgaFSfvFjzvac7dSxsA8MnlCFtPmBZkd0YFCU3o-cjugpAo$
>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls-
>>> reg-review__;!!GjvTz_vk!R1N5_LR5owtUtnBawvy-
>>> JIRAAWeUE12VjgaFSfvFjzvac7dSxsA8MnlCFtPmBZkd0YFCU3o-cjugpAo$>
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> tls-reg-review mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls-
>>> reg-review__;!!GjvTz_vk!R1N5_LR5owtUtnBawvy-
>>> JIRAAWeUE12VjgaFSfvFjzvac7dSxsA8MnlCFtPmBZkd0YFCU3o-cjugpAo$
>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls-
>>> reg-review__;!!GjvTz_vk!R1N5_LR5owtUtnBawvy-
>>> JIRAAWeUE12VjgaFSfvFjzvac7dSxsA8MnlCFtPmBZkd0YFCU3o-cjugpAo$>
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> tls-reg-review mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls-reg-review
>>> 
>