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
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
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
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
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
Hello,
The X25519MLKEM768 scheme defined in the document is a concatenation of
MLKEM768 and X25519, why is it not named MLKEM768X25519 instead?
For SecP256r1MLKEM768, the naming makes sense since it's a concatenation of
P256 and MLKEM768.
Apologies if this has already been asked before.
Cheers,
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
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
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,
Hi Kris and Deirdre,
We talked about cases of X||Y internally at NIST.
1) X is a raw shared secret such as Z in 56C and Y is the output of a
NIST-approved PQ KEM. Their order can be reversed. This should be approved for
PQ security solution.
2) X is an output of a NIST-approved classical key
Hi Eric and all,
NIST allows the shared secret key, called K, of a ML-KEM to be in the place of
Z (a raw shared secret) in 56C.
In 56C, Z can be X||Y, but X must be either a raw shared secret generated by a
NIST-approved key agreement/establishment method or K.
A X25519’s raw shared secret or
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
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
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
The following errata report has been held for document update
for RFC8447, "IANA Registry Updates for TLS and DTLS".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6009
--
Status: Held for D
The following errata report has been rejected for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6148
--
Status: Rejected
Ty
The following errata report has been rejected for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6150
--
Status: Rejected
Ty
The following errata report has been held for document update
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7073
--
S
The following errata report has been rejected for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6127
--
Status: Rejected
Ty
I have reviewed draft-ietf-tls-rfc8446bis-11.
I think it is becoming commonplace to list errata incorporated into the
document as informative references (eg [Err6151]) and then list in the
Abstract or Introduction which errata the bis document resolves. Please
consider doing this.
I have just gon
Hi! We had a fairly well attended virtual interim on 1 October; 40 attendees to
be exact. Slides and minutes for and a recording of the interim can be found
here:
https://datatracker.ietf.org/meeting/interim-2024-tls-01/session/tls
My purposely brief summary is that we did a pretty good job of s
The following errata report has been held for document update
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6151
--
S
The following errata report has been rejected for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6137
--
Status: Rejected
Ty
The following errata report has been rejected for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6152
--
Status: Rejected
Ty
The following errata report has been rejected for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7620
--
Status: Rejected
Ty
The following errata report has been held for document update
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6140
--
S
The minutes have not been posted to that page yet.
Russ
> On Oct 17, 2024, at 2:24 PM, Sean Turner wrote:
>
> Hi! We had a quick (45min) interim to discuss the FATT Process. Slides &
> minutes for (and eventually a recording of) the session can be found here:
> https://datatracker.ietf.org/mee
I don't think this erratum is correct. This is due to some weird allowance
in PSK acceptance. You are allowed to use the PSK with a different cipher
suite if the hash portion matches. But early data requires an exact match
on top of it.
On Thu, Oct 17, 2024, 12:21 RFC Errata System
wrote:
> The
HFDU is good. Many X25519 implementations won't be concerned about this
detail, but others might. We might fix it in one of two ways: twiddle those
bits as X25519 requires or note that the private values were the untwiddled/raw
values.
On Mon, Mar 18, 2024, at 15:26, Sean Turner wrote:
> Hi!
The following errata report has been held for document update
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7003
--
S
The following errata report has been rejected for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6120
--
Status: Rejected
Ty
The following errata report has been rejected for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6121
--
Status: Rejected
Ty
Hi all,
Thanks everyone for a very productive interim! It was nice to see the
interest in solving this problem, and to hear from the experiences of folks
in the TLS ecosystem. While we client folks may try our best to anticipate
the needs of server operators, there’s really no substitute for heari
> On Oct 17, 2024, at 15:29, Paul Wouters
> wrote:
>
> RFC8996 seems to be a broken reference ? Might be a tooling issue but it is
> already broken in the xml file on the datatracker.
I’ll check on this.
https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8996.xml seems to just
hang.
sp
Hi! We had a quick (45min) interim to discuss the FATT Process. Slides &
minutes for (and eventually a recording of) the session can be found here:
https://datatracker.ietf.org/meeting/interim-2024-tls-02/session/tls
The summary is that the process described in the slides is basically the right
The following errata report has been rejected for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6126
--
Status: Rejected
Ty
The following errata report has been rejected for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6124
--
Status: Rejected
Ty
The following errata report has been rejected for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6144
--
Status: Rejected
Ty
The following errata report has been held for document update
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6147
--
S
The following errata report has been rejected for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6143
--
Status: Rejected
Ty
The following errata report has been rejected for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6145
--
Status: Rejected
Ty
Based on the snippet here, I agree with David.
On Fri, Oct 18, 2024, at 07:19, David Benjamin wrote:
> I don't think this erratum is correct. This is due to some weird
> allowance in PSK acceptance. You are allowed to use the PSK with a
> different cipher suite if the hash portion matches. But e
Whoops - Corrected!
spt
> On Oct 17, 2024, at 17:14, Russ Housley wrote:
>
> The minutes have not been posted to that page yet.
>
> Russ
>
>> On Oct 17, 2024, at 2:24 PM, Sean Turner wrote:
>>
>> Hi! We had a quick (45min) interim to discuss the FATT Process. Slides &
>> minutes for (and e
It was resolved as Hold For Document Update, because the bis document
resolved it by saying:
In order to accept early data, the server MUST have selected the first key
offered in the client's "pre_shared_key" extension. In addition, it MUST
verify that the following values are the same as those as
On Fri, Oct 18, 2024, at 13:33, Paul Wouters wrote:
> So no textual changes from the bis will be done for this errata, and
> this bis text is considered closing that errata issue.
>
> if you still disagree, please let me know and share your proposed
> changed text for the bis document :)
The bis
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
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
* 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
>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)
_
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
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
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
The following errata report has been rejected for RFC8446,
"The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6136
--
Status: Rejected
Ty
Paul,
Technically we did address this:
https://github.com/tlswg/tls13-spec/pull/1364/files
spt
> On Oct 17, 2024, at 13:22, RFC Errata System
> wrote:
>
> The following errata report has been rejected for RFC8446,
> "The Transport Layer Security (TLS) Protocol Version 1.3".
>
> -
+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-ecdh
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
57 matches
Mail list logo
