On Fri, 18 Oct 2024 at 15:12, Salz, Rich
wrote:
> To me, this trumps geek esthetics about making things line up.
>
To be clear, my objection is not aesthetic or even about implementation
effort. My concern is about rubber-stamping whatever unprincipled things
that NIST comes up with.
I also agr
h as "c ap
traffic" and the transcript.
When we have a decision on this matter, our team will share it with you.
Regards,
Quynh.
From: David Benjamin
Sent: Wednesday, October 23, 2024 11:52 AM
To: Joseph Birr-Pixton
Cc: Salz, Rich ; John Mattsson
; tls@ietf.org
Subject: [TLS] Re:
Oh I definitely agree there is a deeper problem here. It seems like NIST
wrote something over-restrictive and then folks did a preemptive compliance
maneuver to try to satisfy it. This is not a good way to do protocol
development and hampers what should ultimately have been the goal for
everyone: m
I agree. X25518MLKEM768 has shipped, so we should just leave it alone.Best,Chris On Oct 17, 2024, at 11:38 AM, David Benjamin wrote:Specifically the X25519MLKEM768 is widely deployed already. I'm not aware of any deployments of the other hybrids. I am very strongly opposed to incompatible changes
> There will need to be key exchange groups that are FIPS compatible,
so either it will happen in this i-d, or a new one will be published.
> I'm of the opinion that it's better to have fewer codepoints to test
interoperability of.
> Especially if the change is completely inconsequential to peopl
On Thursday, 17 October 2024 18:31:05 CEST, John Mattsson wrote:
We should have a consistent ordering of [EC, PQ] in both the
names and the key schedule. I.e., the code should be
>consistent with the naming and either the EC or the PQC ought
to always come first.
+1
(if FIPS leads to weird
LS List
Subject: [TLS] Re: X25519MLKEM768 in draft-kwiatkowski-tls-ecdhe-mlkem-02
Just to clarify Kris, you are _asking_ if there is a plan? I don't know if
Quynh can comment but
Yes, I was wondering if there is a concrete plan to relax the ordering
requirement. After yesterday's me
Hiya,
On 10/17/24 16:37, David Benjamin wrote:
Specifically the X25519MLKEM768 is widely deployed already. I'm not aware
of any deployments of the other hybrids. I am very strongly opposed to
incompatible changes to the widely deployed one for something this trivial
and unimportant.
+1
S.
_
Just to clarify Kris, you are _asking_ if there is a plan? I don't know
if Quynh can comment but
Yes, I was wondering if there is a concrete plan to relax the ordering
requirement. After yesterday's meeting, I understood
that this is something NIST may consider.
[1] See Mike's notes
https://ma
On Thu, Oct 17, 2024 at 8:36 AM Salz, Rich
wrote:
>
> * We should have a consistent ordering of [EC, PQ] in both the names and the
> key schedule. I.e., the code should be consistent with the naming and either
> the EC or the PQC ought to always come first.
>
>
>
> That would be nice, but it app
+1 to choosing reasonable and consistent names that make sense, instead of
being overly concerned with whether they exactly replicate the implementation.
-Tim
From: David Benjamin
Sent: Thursday, October 17, 2024 11:33 AM
To:
Subject: [TLS] Re: X25519MLKEM768 in draft-kwiatkowski-tls
On Thu, Oct 17, 2024 at 15:36:02 +, Salz, Rich wrote:
> * Can we please have a separator between them, as in MLKEM768_X25519?
>
> Yes please!
I would also like to suggest a capitalisation consistent with existing
IANA groups:
x25519_mlkem768 and secp256r1_mlkem768 (or perhaps secp256r1_MLKE
>We should have a consistent ordering of [EC, PQ] in both the names and the key
>schedule. I.e., the code should be >consistent with the naming and either the
>EC or the PQC ought to always come first.
+1
(if FIPS leads to weird solutions, I think IETF should ignore FIPS for one of
them)
_
Specifically the X25519MLKEM768 is widely deployed already. I'm not aware
of any deployments of the other hybrids. I am very strongly opposed to
incompatible changes to the widely deployed one for something this trivial
and unimportant.
I am not personally opposed to changes to the others if the W
* We should have a consistent ordering of [EC, PQ] in both the names and the
key schedule. I.e., the code should be consistent with the naming and either
the EC or the PQC ought to always come first.
That would be nice, but it appears that the requirements that some find
important (e.g., for me
While this whole situation is indeed ridiculous (there is obviously no
security reason to use one or the other order and any certification systems
that believe otherwise are clearly wrong and should be fixed), this draft
with this order is now running code in several large deployments. I don't
thin
My $.02.
* We should have a consistent ordering of [EC, PQ] in both the names and
the key schedule. I.e., the code should be consistent with the naming and
either the EC or the PQC ought to always come first.
* I don't have a strong opinion about which should go first.
* Can we please have a separ
Bas Westerbaan wrote:
> The number of people that actually implement these hybrid KEMs is much
> smaller than the number of people that need to make a choice based on their
> name. How do we explain that one is called MLKEM768X25519 and the other
> SecP256r1MLKEM768?
"In hybrid key exchanges, the
, October 17, 2024 9:24 AM
To: Kris Kwiatkowski
Cc: CJ Tjhai ;
draft-kwiatkowski-tls-ecdhe-mlkem.auth...@ietf.org; TLS List
Subject: [TLS] Re: X25519MLKEM768 in draft-kwiatkowski-tls-ecdhe-mlkem-02
Just to clarify Kris, you are _asking_ if there is a plan? I don't know if
Quynh can commen
Just to clarify Kris, you are _asking_ if there is a plan? I don't know
if Quynh can comment but
NIST have said publicly that they plan to clarify hybrid KEMs in the
forthcoming SP 800-227:
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/6_D0mMSYJZY/m/3DwwIAJXAwAJ
> is there a plan to cha
It would in fact be great to get an official answer on whether either order
is FIPS-compatible, as it clear that the order doesn't matter for security
when used in TLS 1.3 as written in tls-hybrid-design (fixed lengths,
everything public is going into the key schedule anyway, etc).
There are other
.
From: Eric Rescorla
Sent: Thursday, October 17, 2024 8:54 AM
To: Joseph Birr-Pixton
Cc: CJ Tjhai ;
draft-kwiatkowski-tls-ecdhe-mlkem.auth...@ietf.org; TLS List
Subject: [TLS] Re: X25519MLKEM768 in draft-kwiatkowski-tls-ecdhe-mlkem-02
Can we get a ruling on this from NIST? Quynh?
-Ekr
On Thu
So it's pretty clear that TLS 1.3 is FIPS-able, because it has been
validated multiple times. But it's not just a blessed exception, or that
FIPS is 'not sensitive' to the particulars - it looks to be using HKDF in
compliance with SP 800-133rev2 (Section 6.3 Option #3), SP 800-56Crev2, and
SP 800-1
Indeed, that would be good inside.
Additionally, is there a plan to change SP800-56Cr2, so that it allows to
use combination of two shared secrets where one was generated by FIPS-approved
technique, BUT concatenated in any order.
I understand it is potentially more complicated for ACVP testing,
Can we get a ruling on this from NIST? Quynh?
-Ekr
On Thu, Oct 17, 2024 at 2:32 AM Joseph Birr-Pixton
wrote:
> Please could we... not?
>
> It certainly is one interpretation of that section in SP800-56C. Another
> is that TLS1.3 falls outside SP800-56C, because while HKDF kinda looks like
> se
certified SecP2561r1 crypto backend and not yet certified MLKEM?
This is precisely the problem we want to address with P-256.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
Any reason why we won’t put MLKEM in front of ECDHE key share for all the curves both on the wire and in the naming convention?That would be consistent and harder to get wrong.Or would this make an implementation of hybrid MLKEM and SecP256r1 non FIPS certified in the case of using certified SecP25
Please could we... not?
It certainly is one interpretation of that section in SP800-56C. Another is
that TLS1.3 falls outside SP800-56C, because while HKDF kinda looks like
section 5, none of the allowed options for key expansion specified in
SP800-108 (and revs) are the same as HKDF-Expand. "KDF
The number of people that actually implement these hybrid KEMs is much
smaller than the number of people that need to make a choice based on their
name. How do we explain that one is called MLKEM768X25519 and the other
SecP256r1MLKEM768? That'll cause more confusion worldwide over the coming
decade
Personally, I prefer a name change to MLKEM768X25519.
Cheers,
CJ
On Thu, 17 Oct 2024 at 08:57, Kris Kwiatkowski wrote:
> Yes, we switched the order. We want MLKEM before X25519, as that
> presumably can be FIPS-certified.
> According to
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NI
Yes, we switched the order. We want MLKEM before X25519, as that presumably
can be FIPS-certified.
According to
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf,
section 2,
the shared secret from the FIPS-approved algorithm must precede the one that
is not approved. X
Did we really switch the order gratuitously on the wire between them?
On Thu, Oct 17, 2024 at 12:02 AM CJ Tjhai
wrote:
>
> Hello,
>
> The X25519MLKEM768 scheme defined in the document is a concatenation of
> MLKEM768 and X25519, why is it not named MLKEM768X25519 instead?
>
> For SecP256r1MLKEM7
32 matches
Mail list logo
