[TLS] Re: X25519MLKEM768 in draft-kwiatkowski-tls-ecdhe-mlkem-02

2024-10-18 Thread Kris Kwiatkowski 
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://mailarchive.ietf.org/arch/msg/spasm/0HYpMgRiqUF61Z90BYuS-RfBWDU/


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 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.

On Thu, Oct 17, 2024 at 9:10 AM Kris Kwiatkowski  wrote:

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, but it
seems it would solve a problem. Does order matter from the security
perspective?

On 17/10/2024 13:53, Eric Rescorla wrote:

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 section 5, none of the allowed options for key
expansion specified in SP800-108 (and revs) are the same as
HKDF-Expand. "KDF in Feedback Mode" gets close, but (ironically)
the order and width of inputs are different. Given people have
shipped FIPS-approved TLS1.3 many times by now (with approved HKDF
implementations under SP800-56C!), we can conclude that FIPS
approval is simply not sensitive to these sorts of details.

I also note that tls-hybrid-design says:

> The order of shares in the concatenation
> MUST be the same as the order of algorithms indicated in the
> definition of the NamedGroup.

So we're not even being consistent with something past WGLC?

Thanks,
Joe

On Thu, 17 Oct 2024 at 08:58, 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/NIST.SP.800-56Cr2.pdf,
section 2,
the shared secret from the FIPS-approved algorithm must precede
the one that is not approved. X25519
is not FIPS-approved hence MLKEM goes first. P-256 is
FIPS-approved.

The ordering was mentioned a few times, and there was some
discussion on github [1] about it. But,
maybe the conclusion should be just to change the name
X25519MLKEM768 -> MLKEM768X25519 (any opinion?)
That would be just a name change, so the code point value
should stay the same.

Cheers,
Kris

[1]

https://github.com/open-quantum-safe/oqs-provider/issues/503#issuecomment-2349478942

On 17/10/2024 08:24, Watson Ladd wrote:

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 SecP256r1MLKEM768, the naming makes sense since it's a 
concatenation of P256 and MLKEM768.

Apologies if this has already been asked before.

Cheers,
CJ




PQ Solutions Limited (trading as ‘Post-Quantum’) is a private 
limited company incorporated in England and Wales with registered number 
06808505.

This email is meant only for the intended recipient. If you have 
received this email in error, any review, use, dissemination, distribution, or 
copying of this email is strictly prohibited. Please notify us immediately of 
the error by return email and please delete this message from your system. 
Thank you in advance for your cooperation.

For more information about Post-Quantum, please visitwww.post-quantum.com 
.

In the course of our business relationship, we may collect, store and 
transfer information about you. Please see our privacy notice 
atwww.post-quantum.com/privacy-policy/ 
 to learn a

[TLS] Re: X25519MLKEM768 in draft-kwiatkowski-tls-ecdhe-mlkem-02

2024-10-18 Thread Alicja Kario 

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 solutions, I think IETF should ignore 
FIPS for one of them)


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 people not
needing FIPS compatibility.

--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: X25519MLKEM768 in draft-kwiatkowski-tls-ecdhe-mlkem-02

2024-10-18 Thread Stephen Farrell 


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.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: X25519MLKEM768 in draft-kwiatkowski-tls-ecdhe-mlkem-02

2024-10-18 Thread Salz, Rich 
> 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 people not
needing FIPS compatibility.

I agree with all of this.

There are those who think parts of FIPS are silly.  I am one of them. But "the 
customer is always right" and the customers often want, or have to have, FIPS. 
To me, this trumps geek esthetics about making things line up.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: X25519MLKEM768 in draft-kwiatkowski-tls-ecdhe-mlkem-02

2024-10-18 Thread John Mattsson 
>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.

I think it would make even more sense if NIST just approved X25519 and X448. 
The vast majority of TLS/HTTPS/QUIC/SSH connections today already use X25519. 
It would make sense if NIST approved this. NIST has already specified 
Curve25519 and Curve448 in SP 800-186. The Montogomery curves are faster, have 
better encoding, and are more robust than Weierstraß curves. Ericsson's plan is 
to use as much x25519, x448, Ed25519, and Ed448 as possible in PQC hybrids. We 
also plan to use as much SHA-3/SHAKE/cSHAKE/KMAC as possible.

Cheers,
John

From: Kris Kwiatkowski 
Date: Friday, 18 October 2024 at 13:36
To: Deirdre Connolly 
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 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://mailarchive.ietf.org/arch/msg/spasm/0HYpMgRiqUF61Z90BYuS-RfBWDU/


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 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.

On Thu, Oct 17, 2024 at 9:10 AM Kris Kwiatkowski 
mailto:k...@amongbytes.com>> wrote:

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, but it
seems it would solve a problem. Does order matter from the security perspective?
On 17/10/2024 13:53, Eric Rescorla wrote:
Can we get a ruling on this from NIST? Quynh?

-Ekr


On Thu, Oct 17, 2024 at 2:32 AM Joseph Birr-Pixton 
mailto:jpix...@gmail.com>> 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 
section 5, none of the allowed options for key expansion specified in SP800-108 
(and revs) are the same as HKDF-Expand. "KDF in Feedback Mode" gets close, but 
(ironically) the order and width of inputs are different. Given people have 
shipped FIPS-approved TLS1.3 many times by now (with approved HKDF 
implementations under SP800-56C!), we can conclude that FIPS approval is simply 
not sensitive to these sorts of details.

I also note that tls-hybrid-design says:

> The order of shares in the concatenation
> MUST be the same as the order of algorithms indicated in the
> definition of the NamedGroup.

So we're not even being consistent with something past WGLC?

Thanks,
Joe

On Thu, 17 Oct 2024 at 08:58, Kris Kwiatkowski 
mailto:k...@amongbytes.com>> 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/NIST.SP.800-56Cr2.pdf, 
section 2,
the shared secret from the FIPS-approved algorithm must precede the one that is 
not approved. X25519
is not FIPS-approved hence MLKEM goes first. P-256 is FIPS-approved.

The ordering was mentioned a few times, and there was some discussion on github 
[1] about it. But,
maybe the conclusion should be just to change the name X25519MLKEM768 -> 
MLKEM768X25519 (any opinion?)
That would be just a name change, so the code point value should stay the same.

Cheers,
Kris

[1] 
https://github.com/open-quantum-safe/oqs-provider/issues/503#issuecomment-2349478942
On 17/10/2024 08:24, Watson Ladd wrote:

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 SecP256r1MLKEM768, the naming makes sense since it's a concatenation of 
P256 and MLKEM768.



Apologies if this has already been asked before.



Cheers,

CJ









PQ Solutions Limited (trading as ‘Post-Quantum’) is a private limited company 
incorporated in England and Wales with registered number 06808505.



This email is meant only for the intended recipient. If you have received this 
email in error, any review, use, dissemination, distribution, or copying of 
this email is strictly prohibited. Please notify us immediately of the er

[TLS] Re: AD review draft-ietf-tls-rfc8446bis-11

2024-10-18 Thread Paul Wouters 

On Thu, 17 Oct 2024, Sean Turner wrote:


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.


This is a tooling bug and a workaround was put in place. So should not
require any changes by the document authors.

Paul

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] [Errata Held for Document Update] RFC8448 (5645)

2024-10-18 Thread RFC Errata System 
The following errata report has been held for document update 
for RFC8448, "Example Handshake Traces for TLS 1.3". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5645

--
Status: Held for Document Update
Type: Technical

Reported by: Anthony Mai 
Date Reported: 2019-02-28
Held by: Paul Wouters (IESG)

Section: 2

Original Text
-
   Ephemeral private keys are shown as they are generated in the traces.

Corrected Text
--
   Ephemeral private keys are shown as they are generated in the traces.
Note that X25519 private keys are trimmed in accordance to [RFC 7748]
Section 5, before use. This is done by clearing bit 0 to 2 of the first
byte and bit 7 of the last byte. And then set bit 6 of the last byte.

Notes
-
On page 3,5,16,20,29,43,44,55,57, there are ten X25519 ephemeral private
keys listed. None of these private key value, when used directly in X25519
calculation, will yield the associated public key listed. These private key
values are not the actual values used. Instead up to 5 bits are modified as
recommended by RFC 7748 section 5. Some implementations may choose NOT to
do such trimming, and it does not affect the connectivity, as the private
keys are never sent over the wire and does not affect network behavior.

Not clarifying how the X25519 private keys were modified before using could
cause serious confusion. I personally struggled for a day before figuring
out this little obscure detail.

--
RFC8448 (draft-ietf-tls-tls13-vectors-07)
--
Title   : Example Handshake Traces for TLS 1.3
Publication Date: January 2019
Author(s)   : M. Thomson
Category: INFORMATIONAL
Source  : Transport Layer Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

2024-10-18 Thread The IESG 

The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'The Transport Layer Security (TLS)
Protocol Version 1.3'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2024-11-01. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This document specifies version 1.3 of the Transport Layer Security
   (TLS) protocol.  TLS allows client/server applications to communicate
   over the Internet in a way that is designed to prevent eavesdropping,
   tampering, and message forgery.

   This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes
   RFCs 5077, 5246, 6961, 8422, and 8446.  This document also specifies
   new requirements for TLS 1.2 implementations.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information: 
rfc8439: ChaCha20 and Poly1305 for IETF Protocols (Informational - Internet 
Research Task Force (IRTF) stream)
rfc6962: Certificate Transparency (Experimental - Internet Engineering Task 
Force (IETF) stream)




___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org