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

[Bas Westerbaan]

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
decades, than the few implementers who confuse the order on the wire
this year.


On Thu, Oct 17, 2024 at 10:54 AM CJ Tjhai  wrote:

> 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/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 visit www.post-quantum.com.
>>
>> In the course of our business relationship, we may collect, store and 
>> transfer information about you. Please see our privacy notice at 
>> www.post-quantum.com/privacy-policy/ to learn about how we use this 
>> information.
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
>>
> --
> 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 visit www.post-quantum.com
> .
>
> In the course of our business relationship, we may collect, store and
> transfer information about you. Please see our privacy notice at
> www.post-quantum.com/privacy-policy/ to learn about how we use this
> information.
>
___
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

[Joseph Birr-Pixton]

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 visit www.post-quantum.com.
>
> In the course of our business relationship, we may collect, store and 
> transfer information about you. Please see our privacy notice at 
> www.post-quantum.com/privacy-policy/ to learn about how we use this 
> information.
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
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

[Kris Kwiatkowski]

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 about how we use this 
information.
___
TLS mailing list --tls@ietf.org
To unsubscribe send an email totls-le...@ietf.org


___
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

[Watson Ladd]

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 visit www.post-quantum.com.
>
> In the course of our business relationship, we may collect, store and 
> transfer information about you. Please see our privacy notice at 
> www.post-quantum.com/privacy-policy/ to learn about how we use this 
> information.
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org



-- 
Astra mortemque praestare gradatim

___
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

[Kris Kwiatkowski]

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

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

[CJ Tjhai]

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/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 visit www.post-quantum.com.
>
> In the course of our business relationship, we may collect, store and 
> transfer information about you. Please see our privacy notice at 
> www.post-quantum.com/privacy-policy/ to learn about how we use this 
> information.
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
>

-- 

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 visit www.post-quantum.com 
.

In the course of our business relationship, 
we may collect, store and transfer information about you. Please see our 
privacy notice at www.post-quantum.com/privacy-policy/ 
 to learn about how we use 
this information.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[CJ Tjhai]

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 visit www.post-quantum.com 
.

In the course of our business relationship, 
we may collect, store and transfer information about you. Please see our 
privacy notice at www.post-quantum.com/privacy-policy/ 
 to learn about how we use 
this information.
___
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

[Yaroslav Rosomakho]

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 SecP2561r1 crypto backend and not yet certified MLKEM?-yaroslavOn 17 Oct 2024, at 13:18, 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? That'll cause more confusion worldwide over the coming decades, than the few implementers who confuse the order on the wire this year.On Thu, Oct 17, 2024 at 10:54 AM CJ Tjhai  wrote:Personally, I prefer a name change to MLKEM768X25519.Cheers,CJOn 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/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 visit www.post-quantum.com.

In the course of our business relationship, we may collect, store and transfer information about you. Please see our privacy notice at www.post-quantum.com/privacy-policy/ to learn about how we use this information.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

  
  

  




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 visit www.post-quantum.com.In the course of our business relationship, we may collect, store and transfer information about you. Please see our privacy notice at www.post-quantum.com/privacy-policy/ to learn about how we use this information.
___TLS mailing list -- tls@ietf.orgTo unsubscribe send an email to tls-le...@ietf.org___
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

[Eric Rescorla]

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 visit www.post-quantum.com.
>>
>> In the course of our business relationship, we may collect, store and 
>> transfer information about you. Please see our privacy notice at 
>> www.post-quantum.com/privacy-policy/ to learn about how we use this 
>> information.
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
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

[Kris Kwiatkowski]

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 about how we use this 
information.
___
TLS mailing list --tls@ietf.org
To unsubscribe send an email totls-le...@ietf.org

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

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
___
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

[Dang, Quynh H. (Fed)]

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 establishment/agreement 
method (not a raw shared secret, not Z) and Y is the output of a NIST-approved 
PQ KEM. Their order can be reversed. This should be approved for PQ security 
solution.

3) Both X and Y are outputs of NIST-approved PQ secure KEMs. Their order can be 
reversed. This should be approved for PQ security solution.

4) Both X and Y are outputs of NIST-approved PQ secure KEMs. Later, if only one 
of them is still NIST-approved PQ secure KEM.

But I don’t know an official policy from my management at this moment.

Regards,
Quynh.






From: Deirdre Connolly 
Sent: Thursday, 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 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 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 error by 
return email and please delete this message from your system. Thank you in 
advance for your cooperation.



For more

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

[Dang, Quynh H. (Fed)]

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 a pseudorandom key generated from it is not a 
NIST-approved X.

A NIST-approved ECDH method produces shared secret key(s), not a raw DH shared 
secret because it always has a KDF which outputs the desired key(s) (the 
desired keying material) the application on top of it needs.

Regards,
Quynh.

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, 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 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 visit 
www.post-quantum.com.



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

___

TLS mailing list -- tls@ietf.org

To unsubscribe send an email to tls-le...@ietf.org
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
___
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

[Deirdre Connolly]

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-108 - Filippo Valsorda went down the rabbit hole to nail this down:
https://words.filippo.io/dispatches/fips-hkdf/

On the hybrids, the orders should match the names to cohere with
tls-hybrid-design, and I think the authors intend to at least make the
names match the order at least. Whether having different orders
amongst different `NamedGroup`s just because one achieves FIPS one way and
the other, doesn't (or not as in as many months because of the FIPS crypto
module validation lead times), seems a bit gross as these documents are not
just serving the handful of implementers deploying hybrid in the next N
months, they may last indefinitely and have to serve implementers
indefinitely. Minimizing confusion is not nothing





On Thu, Oct 17, 2024 at 8:55 AM 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 visit www.post-quantum.com.
>>>
>>> In the course of our business relationship, we may collect, store and 
>>> transfer information about you. Please see our privacy notice at 
>>> www.post-quantum.com/privacy-policy/ to learn about how we use this 
>>> information.
>>> ___
>>> TLS mailing list -- tls@ietf.org
>>> To unsubscribe send an email to tls-le...@ietf.org
>>>
>>> ___
>>> TLS mailing list -- tls@ietf.org
>>> To unsubscribe send an email to tls-le...@ietf.org
>>>
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
> ___
> TLS mailing list -- tls@ietf.org
> To un

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

[Deirdre Connolly]

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 settings / combiners where the order can matter but this
design in TLS 1.3 is not one

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 visit www.post-quantum.com.
>>>
>>> In the course of our business relationship, we may collect, store and 
>>> transfer information about you. Please see our privacy notice at 
>>> www.post-quantum.com/privacy-policy/ to learn about how we use this 
>>> information.
>>> ___
>>> TLS mailing list -- tls@ietf.org
>>> To unsubscribe send an email to tls-le...@ietf.org
>>>
>>> ___
>>> TLS mailing list -- tls@ietf.org
>>> To unsubscribe send an email to tls-le...@ietf.org
>>>
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
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

[Deirdre Connolly]

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 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 visit www.post-quantum.com.
>>>
>>> In the course of our business relationship, we may collect, store and 
>>> transfer information about you. Please see our privacy notice at 
>>> www.post-quantum.com/privacy-policy/ to learn about how we use this 
>>> information.
>>> ___
>>> TLS mailing list -- tls@ietf.org
>>> To unsubscribe send an email to tls-le...@ietf.org
>>>
>>> ___
>>> TLS mailing list -- tls@ietf.org
>>> To unsubscribe send an email to tls-le...@ietf.org
>>>
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- t

[TLS] [Errata Held for Document Update] RFC8447 (6009)

[RFC Errata System]

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 Document Update
Type: Editorial

Reported by: Benjamin Kaduk 
Date Reported: 2020-03-07
Held by: Paul Wouters (IESG)

Section: 14

Original Text
-
   o  Added a "Recommended" column to the registry.  X.509 and Raw


Corrected Text
--
   o  Added a "Recommended" column to the registry.  X509 and Raw


Notes
-
Update to match https://www.rfc-editor.org/errata/eid5976

--
RFC8447 (draft-ietf-tls-iana-registry-updates-05)
--
Title   : IANA Registry Updates for TLS and DTLS
Publication Date: August 2018
Author(s)   : J. Salowey, S. Turner
Category: PROPOSED STANDARD
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] [Errata Rejected] RFC8446 (6148)

[RFC Errata System]

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
Type: Editorial

Reported by: Ben Smyth 
Date Reported: 2020-04-29
Rejected by: Paul Wouters (IESG)

Section: 4.2.10

Original Text
-
The selected ALPN [RFC7301] protocol, if any

Corrected Text
--
The selected ALPN [RFC7301] protocol, if extension 
application_layer_protocol_negotiation is present

Notes
-

 --VERIFIER NOTES-- 
   rejected by WG

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
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] [Errata Rejected] RFC8446 (6150)

[RFC Errata System]

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
Type: Editorial

Reported by: Ben Smyth 
Date Reported: 2020-04-29
Rejected by: Paul Wouters (IESG)

Section: GLOBAL

Original Text
-
Note that certificate-based client authentication is not available 
in PSK handshake flows (including 0-RTT). 

Corrected Text
--
Note that certificate-based client authentication is not available 
in PSK handshake flows (including 0-RTT), post-handshake 
certificate-based client authentication is possible.

Notes
-

 --VERIFIER NOTES-- 
   rejected by WG

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
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] [Errata Held for Document Update] RFC8446 (7073)

[RFC Errata System]

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

--
Status: Held for Document Update
Type: Technical

Reported by: Ben Smyth 
Date Reported: 2022-08-06
Held by: Paul Wouters (IESG)

Section: 4.4

Original Text
-
These messages are encrypted under keys derived from the 
[sender]_handshake_traffic_secret.

Corrected Text
--
These messages are encrypted under keys derived from the 
[sender]_handshake_traffic_secret, except for post-handshake authentication

Notes
-
There's an exception

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
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] [Errata Rejected] RFC8446 (6127)

[RFC Errata System]

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
Type: Editorial

Reported by: Ben Smyth 
Date Reported: 2020-04-24
Rejected by: Paul Wouters (IESG)

Section: 4.1.2.

Original Text
-
If a "key_share" extension was supplied in the HelloRetryRequest,
replacing the list of shares with a list containing a single
KeyShareEntry from the indicated group.

Corrected Text
--
If a "key_share" extension was supplied in the HelloRetryRequest,
replacing the list of shares with a list containing a single
KeyShareEntry from the indicated group. Note: A "key_share" 
extension may not be supplied in a HelloRetryRequest message 
when a server receives  an "early_data" (Section 4.2.10).

Notes
-

 --VERIFIER NOTES-- 
   rejected by WG

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
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] AD review draft-ietf-tls-rfc8446bis-11

[Paul Wouters]

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 gone through all Reported errata against 8446 and confirmed
there are no unresolved errata after going through them all.

Otherwise, I only have two nits:

RFC8996 seems to be a broken reference ? Might be a tooling issue but it is
already broken in the xml file on the datatracker.

  [RFC8937] describes a way way for security protocol

A duplicate "way" needs to be removed.

I'm starting a 4 week IETF Last Call on this document now, so the Last Call
won't end during the IETF week.

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

[TLS] TLS WG Interim (Trust Tussle) summary (was Re: interim-2024-tls-01 interim approved)

[Sean Turner]

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 sticking to the 
intended agenda, which was focusing on the problem statement. We did two polls 
that both resulted in consensus for "Yes"; the polls follow:

1. Do you understand the problem we are trying to solve (see screen)?

Where the screen was from Chris’ Trust Tussle slides (18 of 19):

Avoid client trust conflicts by enabling servers to reliably and efficiently 
support
clients with diverse trust anchor lists, particularly in larger PKIs where the
existing certificate_authorities extension is not viable.

2. Do you think we should work on this problem?

We are now at the point where those that are interested in pursuing this work 
can submit an I-D for WG consideration. The working group can then evaluate the 
I-D against the problem statement and other criteria. If there is sufficient 
interest the chairs will run a call for adoption.

Thanks to all those who participated. And, a special shout out to Chris Wood 
for volunteering kick session off!

spt


> On Sep 27, 2024, at 19:35, Sean Turner  wrote:
> 
> To add a little more context about the interim ...
> 
> We are taking a step back to focus on the problem statement/space.  As you 
> can see from the agenda items, we are going to tease out whether we can agree 
> on a problem statement and then wether we should try to solve that problem. 
> As a result, I retitled the topic in the agenda to be “Trust Tussle” to 
> better reflect what we are actually going to discuss. Feel free to read the 
> I-Ds we discussed at IETF 120, draft-davidben-tls-trust-expr and 
> draft-beck-tls-trust-anchor-ids, for background but we are not planning on 
> discussing the I-Ds specifically.
> 
> Cheers,
> spt
> 
>> On Sep 27, 2024, at 13:37, Sean Turner  wrote:
>> 
>> HI! Just another reminder that we have an interim scheduled for Oct 1st @ 
>> 9am Pacific time.  I have uploaded the agenda:*
>> https://datatracker.ietf.org/doc/agenda-interim-2024-tls-01-tls-01/
>> Here is a link to the remote meeting instructions (it’s MeetEcho):
>> https://meetings.conf.meetecho.com/interim/?group=f3d0d4f9-2480-4bdc-8a2d-4765d8aedd73
>> 
>> See you then!
>> 
>> spt
>> 
>> * Thanks Chris!
>> 
>>> On Sep 17, 2024, at 12:18, Sean Turner  wrote:
>>> 
>>> Hi! Another reminder that we have a virtual interim scheduled for 
>>> 2024-10-01 @ 9am Pacific time.  We are still working out the details but 
>>> the topic is Trust Expressions / Trust Anchor Transition.
>>> 
>>> Cheers,
>>> spt
>>> 
 On Sep 10, 2024, at 13:33, Sean Turner  wrote:
 
 Hi! We have scheduled a virtual interim to discuss Trust Expressions / 
 Trust Anchors Transition. We are in the process of defining some ground 
 rules for the meeting as well as setting some expected outcomes, but we 
 wanted to get the interim on the calendar.
 
 Cheers,
 spt
 
> On Sep 10, 2024, at 13:31, IETF Meeting Session Request Tool 
>  wrote:
> 
> 
> An interim meeting for tls has been approved or does not require 
> additional approval.
> A message has been sent to the secretariat requesting the interim be 
> announced.
> 
> 
> -
> Working Group Name: Transport Layer Security
> Area Name: Security Area
> Session Requester: Sean Turner
> 
> Meeting Type: Virtual Meeting
> 
> Session 1:
> 
> Date: 2024-10-01
> Start Time: 12:00 America/New_York
> Duration: 03:00
> Remote Participation Information: 
> https://meetings.conf.meetecho.com/interim/?group=f3d0d4f9-2480-4bdc-8a2d-4765d8aedd73
> Agenda Note: 
> 
> -
> 
 
>>> 
>> 
> 

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

[TLS] [Errata Held for Document Update] RFC8446 (6151)

[RFC Errata System]

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

--
Status: Held for Document Update
Type: Technical

Reported by: Ben Smyth 
Date Reported: 2020-04-30
Held by: Paul Wouters (IESG)

Section: 4.4

Original Text
-
   | Post- | ClientHello ... client  | client_application_traffic_ |
   | Handshake | Finished +  | secret_N|
   |   | CertificateRequest  | |

Corrected Text
--
   | Post- | ClientHello ... client  | [sender]_application_traffic|
   | Handshake | Finished +  | _secret_N   |
   |   | CertificateRequest  | |

Notes
-


--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
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] [Errata Rejected] RFC8446 (6137)

[RFC Errata System]

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
Type: Editorial

Reported by: Ben Smyth 
Date Reported: 2020-04-28
Rejected by: Paul Wouters (IESG)

Section: 4.2.10

Original Text
-
symmetric cipher suite

Corrected Text
--
cipher suite

Notes
-

 --VERIFIER NOTES-- 
   rejected by WG

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
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] [Errata Rejected] RFC8446 (6152)

[RFC Errata System]

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
Type: Technical

Reported by: Ben Smyth 
Date Reported: 2020-05-01
Rejected by: Paul Wouters (IESG)

Section: 4

Original Text
-
Clients MUST check for ["supported_versions"] prior to
processing the rest of the ServerHello (although they will have to 
parse the ServerHello in order to read the extension). -- Section 4.2.1.

Upon receipt of a HelloRetryRequest, the client MUST check the
legacy_version, legacy_session_id_echo, cipher_suite, and
legacy_compression_method as specified in Section 4.1.3 and then
process the extensions, starting with determining the version using
"supported_versions". -- Section 4.1.4

Upon receiving a message with type server_hello, implementations MUST
first examine the Random value... -- Section 4.1.3.


Corrected Text
--


Notes
-
These requirements are seemingly conflicting. I suspect checking for 
"supported_versions" must 
come first, since that may influence subsequent steps, e.g., checking 
legacy_compression_method 
and the Random value. It doesn't seem to matter whether legacy_version, 
legacy_session_id_echo, 
cipher_suite, and legacy_compression_method are checked before the Random 
value, so it doesn't
seem to matter which check is second and which is third. (Noting, as per one of 
my earlier reports,
dated 28 Apr, Section 4.1.3 defines no checks for legacy_version nor 
legacy_compression_method. 
Perhaps the latter should be checked to be zero, aborting with alert 
illegal_parameter if it isn't, as per
Section 4.1.2.)
 --VERIFIER NOTES-- 
   rejected by WG

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
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] [Errata Rejected] RFC8446 (7620)

[RFC Errata System]

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
Type: Technical

Reported by: Ben Smyth 
Date Reported: 2023-08-28
Rejected by: Paul Wouters (IESG)

Section: 6.1

Original Text
-
Each party MUST send a "close_notify" alert before closing its write
side of the connection, unless it has already sent some error alert.
This does not have any effect on its read side of the connection.
Note that this is a change from versions of TLS prior to TLS 1.3 in
which implementations were required to react to a "close_notify" by
discarding pending writes and sending an immediate "close_notify"
alert of their own.  That previous requirement could cause truncation
in the read side.  Both parties need not wait to receive a
"close_notify" alert before closing their read side of the
connection, though doing so would introduce the possibility of
truncation.

Corrected Text
--
Each party MUST send a "close_notify" alert before closing its write
side of the connection, unless it has already sent some error alert.
This SHOULD NOT have any effect on the read side of the sender's connection;
parties SHOULD receive a "close_notify" alert before closing the read side of 
their connection.
Note that this is a change from versions of TLS prior to TLS 1.3 in
which receivers were required to react to a "close_notify" by
discarding pending writes and sending an immediate "close_notify"
alert of their own.  That previous requirement could cause truncation
in the read side.  Both parties need not wait to receive a
"close_notify" alert before closing their read side of the
connection, though doing so would introduce the possibility of
truncation.

Notes
-
As-is there's a specification-level vulnerability: Specification-compliant 
implementations may be vulnerable to truncation attacks.

I suggest using SHOULD NOT & SHOULD for better signposting and to avoid 
specification-level vulnerability.

I also suggest minor tweaks for readability.
 --VERIFIER NOTES-- 
   Rejected by WG. See 
https://github.com/tlswg/tls13-spec/pull/1357/commits/d2a36a8029067cb20ff431fcaa8b3a4e537e4bf6

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
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] [Errata Held for Document Update] RFC8446 (6140)

[RFC Errata System]

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

--
Status: Held for Document Update
Type: Technical

Reported by: Ben Smyth 
Date Reported: 2020-04-29
Held by: Paul Wouters (IESG)

Section: 4.4.2.2.

Original Text
-
This fallback chain SHOULD NOT use the deprecated SHA-1 hash
algorithm in general, but MAY do so if the client's advertisement
permits it, and MUST NOT do so otherwise.

Corrected Text
--
This fullback chain MUST NOT use the deprecated SHA-1 hash,
except if advertised by the client, in which case it MAY.

Notes
-
The original text is difficult to read, eliminating the unnecessary "SHOULD 
NOT" seems to make it 
easier.

Paul Wouters(SEC AD): accepted with slightly different text, keeping the SHOULD 
NOT -> MUST NOT change proposed here

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
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] Re: TLS WG Interim summary (was Re: TLS WG Virtual Interim on FATT Process)

[Russ Housley]

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/meeting/interim-2024-tls-02/session/tls
> 
> The summary is that the process described in the slides is basically the 
> right shape. We obviously have to address how we get formal security analysis 
> if one is requested but the authors do not have the expertise to provide one.
> 
> Also, draft-ietf-tls-8773bis is mid-process and needs a FATT Liaison so the 
> chairs are going to work to get one.
> 
> Cheers,
> spt
> 
>> On Oct 1, 2024, at 20:15, Sean Turner  wrote:
>> 
>> Thanks to all those who participated in the poll. Unfortunately, we couldn’t 
>> schedule a time where everybody could attend. The following time slot had 
>> the most people:
>> 
>>> Begin forwarded message:
>>> 
>>> From: IETF Meeting Session Request Tool 
>>> Subject: interim-2024-tls-02 interim approved
>>> Date: October 1, 2024 at 20:09:13 EDT
>>> To: , 
>>> 
>>> 
>>> An interim meeting for tls has been approved or does not require additional 
>>> approval.
>>> A message has been sent to the secretariat requesting the interim be 
>>> announced.
>>> 
>>> 
>>> -
>>> Working Group Name: Transport Layer Security
>>> Area Name: Security Area
>>> Session Requester: Sean Turner
>>> 
>>> Meeting Type: Virtual Meeting
>>> 
>>> Session 1:
>>> 
>>> Date: 2024-10-16
>>> Start Time: 14:00 America/New_York
>>> Duration: 02:00
>>> Remote Participation Information: 
>>> https://meetings.conf.meetecho.com/interim/?group=7627d881-2175-4086-899f-657548e64b52
>>> Agenda Note: 
>>> 
>>> 
>> 
>> I will make sure to send reminders out prior to meeting. We will also record 
>> this session. And, we plan to have “the plan” out in advance (like a week) 
>> so that those that can’t make it in person can provide comments.
>> 
>> Cheers,
>> spt
>> 
>>> On Sep 23, 2024, at 16:53, Sean Turner  wrote:
>>> 
>>> Hi! Thanks to all those who have already filled out the poll. I am hoping 
>>> to close this out by Friday so I will send daily reminders until then.
>>> 
>>> Cheers,
>>> spt
>>> 
 On Sep 23, 2024, at 12:05, Sean Turner  wrote:
 
 The chairs would like to have an interim to review the FATT (Formal 
 Analysis Triage Team) process. We are still working out the proposal, but 
 we would like to get this meeting scheduled to review any feedback / 
 comments once we do post the process. Please fill out the following with 
 your available times if you are interested in attending:
 
 https://doodle.com/meeting/participate/id/aMoXAp1d
 
 Thanks,
 Deirdre, Joe, & Sean
>>> 
>> 
> 
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org

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

[TLS] Re: [Errata Held for Document Update] RFC8446 (6147)

[David Benjamin]

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 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
>
> --
> Status: Held for Document Update
> Type: Editorial
>
> Reported by: Ben Smyth 
> Date Reported: 2020-04-29
> Held by: Paul Wouters (IESG)
>
> Section: 4.2.10.
>
> Original Text
> -
> In order to accept early data, the server MUST have accepted a PSK
> cipher suiteIn addition, it MUST verify that the
> following values are the same as those associated with the
> selected PSK:
>
> ...
>
> -  The selected cipher suite
>
> Corrected Text
> --
>
>
> Notes
> -
> Accepting the "PSK cipher suite" surely implies the PSK is associated with
> the cipher suite, hence,
> "The selected cipher suite" can be dropped.
>
> Paul Wouters(SEC AD): The text was changed a little to solve this issue
>
> --
> RFC8446 (draft-ietf-tls-tls13-28)
> --
> Title   : The Transport Layer Security (TLS) Protocol Version
> 1.3
> Publication Date: August 2018
> Author(s)   : E. Rescorla
> Category: PROPOSED STANDARD
> 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 mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [Technical Errata Reported] RFC8448 (5645)

[Martin Thomson]

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! This has been lingering for a while, I tend to think we could mark 
> it as HFDU (hold for document update).
>
> spt
>
>> On Feb 28, 2019, at 16:20, RFC Errata System  
>> wrote:
>> 
>> The following errata report has been submitted for RFC8448,
>> "Example Handshake Traces for TLS 1.3".
>> 
>> --
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata/eid5645
>> 
>> --
>> Type: Technical
>> Reported by: Anthony Mai 
>> 
>> 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.
>> 
>> Instructions:
>> -
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party  
>> can log in to change the status and edit the report, if necessary. 
>> 
>> --
>> 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
>> Area: Security
>> Stream  : IETF
>> Verifying Party : IESG
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

[TLS] [Errata Held for Document Update] RFC8446 (7003)

[RFC Errata System]

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

--
Status: Held for Document Update
Type: Technical

Reported by: Ben Smyth 
Date Reported: 2022-06-22
Held by: Paul Wouters (IESG)

Section: 4.6.1.

Original Text
-
At any time after the server has received the client Finished message, it MAY 
send a NewSessionTicket message.

Corrected Text
--
At any time after the server has received both a "psk_key_exchange_modes" 
extension and a Finished message, it MAY send a NewSessionTicket message.



Notes
-
Section 4.2.9. demands 

In order to use PSKs, clients MUST also send a "psk_key_exchange_modes" 
extension.

Hence, an additional restriction is needed in Section 4.6.1.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
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] [Errata Rejected] RFC8446 (6120)

[RFC Errata System]

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
Type: Editorial

Reported by: Ben Smyth 
Date Reported: 2020-04-24
Rejected by: Paul Wouters (IESG)

Section: 1

Original Text
-
the underlying transport is a reliable, in-order data stream



Corrected Text
--
the underlying transport layer is a reliable, in-order stream delivery service

or

the underlying transport protocol is a reliable, in-order stream delivery 
service

or similar

Notes
-
Similar elsewhere
 --VERIFIER NOTES-- 
   rejected by WG.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
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] [Errata Rejected] RFC8446 (6121)

[RFC Errata System]

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
Type: Editorial

Reported by: Ben Smyth 
Date Reported: 2020-04-24
Rejected by: Paul Wouters (IESG)

Section: 1

Original Text
-
cryptographic modes

Corrected Text
--
cryptographic algorithms

Notes
-

 --VERIFIER NOTES-- 
   rejected by WG

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
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] TLS trust anchor IDs

[David Benjamin]

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 hearing
from you all directly.

We’ve recently published draft-beck-tls-trust-anchor-ids-02:

URL:
https://www.ietf.org/archive/id/draft-beck-tls-trust-anchor-ids-02.txt

Status:   https://datatracker.ietf.org/doc/draft-beck-tls-trust-anchor-ids/

HTML:
https://www.ietf.org/archive/id/draft-beck-tls-trust-anchor-ids-02.html

It’s been a while since we’d last mailed about this, so I’ll describe the
changes since -00:

* For convenience, -00 referenced sections of
draft-davidben-tls-trust-exprs, as they both targeted the same problem
statement. Based on the feedback in Vancouver, we are focusing on
draft-beck-tls-trust-anchor-ids and have reworked the document to stand on
its own.

* We’ve added a bit more discussion under Security Considerations, to
further discuss how this work interacts with how PKIs are used in TLS.

* We’ve switched the term “subscriber” to “authenticating party”, for the
role that presents a certificate. “Subscriber” came from the CA/B Forum
Baseline Requirements, where it describes the subscriber or applicant to a
CA’s services. While that does identify this role, it is a little odd in a
document more focused on the TLS client <-> TLS server relationship than
the subscriber <-> CA relationship.

We hope these changes will make the draft easier to understand and invite
you all to take another look. We think it serves as a good starting point
for the working group to build on, and think it is ready to consider for
adoption.

David, Devon, and Bob
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Sean Turner]

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

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

[TLS] TLS WG Interim summary (was Re: TLS WG Virtual Interim on FATT Process)

[Sean Turner]

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 
shape. We obviously have to address how we get formal security analysis if one 
is requested but the authors do not have the expertise to provide one.

Also, draft-ietf-tls-8773bis is mid-process and needs a FATT Liaison so the 
chairs are going to work to get one.

Cheers,
spt

> On Oct 1, 2024, at 20:15, Sean Turner  wrote:
> 
> Thanks to all those who participated in the poll. Unfortunately, we couldn’t 
> schedule a time where everybody could attend. The following time slot had the 
> most people:
> 
>> Begin forwarded message:
>> 
>> From: IETF Meeting Session Request Tool 
>> Subject: interim-2024-tls-02 interim approved
>> Date: October 1, 2024 at 20:09:13 EDT
>> To: , 
>> 
>> 
>> An interim meeting for tls has been approved or does not require additional 
>> approval.
>> A message has been sent to the secretariat requesting the interim be 
>> announced.
>> 
>> 
>> -
>> Working Group Name: Transport Layer Security
>> Area Name: Security Area
>> Session Requester: Sean Turner
>> 
>> Meeting Type: Virtual Meeting
>> 
>> Session 1:
>> 
>> Date: 2024-10-16
>> Start Time: 14:00 America/New_York
>> Duration: 02:00
>> Remote Participation Information: 
>> https://meetings.conf.meetecho.com/interim/?group=7627d881-2175-4086-899f-657548e64b52
>> Agenda Note: 
>> 
>> 
> 
> I will make sure to send reminders out prior to meeting. We will also record 
> this session. And, we plan to have “the plan” out in advance (like a week) so 
> that those that can’t make it in person can provide comments.
> 
> Cheers,
> spt
> 
>> On Sep 23, 2024, at 16:53, Sean Turner  wrote:
>> 
>> Hi! Thanks to all those who have already filled out the poll. I am hoping to 
>> close this out by Friday so I will send daily reminders until then.
>> 
>> Cheers,
>> spt
>> 
>>> On Sep 23, 2024, at 12:05, Sean Turner  wrote:
>>> 
>>> The chairs would like to have an interim to review the FATT (Formal 
>>> Analysis Triage Team) process. We are still working out the proposal, but 
>>> we would like to get this meeting scheduled to review any feedback / 
>>> comments once we do post the process. Please fill out the following with 
>>> your available times if you are interested in attending:
>>> 
>>> https://doodle.com/meeting/participate/id/aMoXAp1d
>>> 
>>> Thanks,
>>> Deirdre, Joe, & Sean
>> 
> 

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

[TLS] [Errata Rejected] RFC8446 (6126)

[RFC Errata System]

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
Type: Editorial

Reported by: Ben Smyth 
Date Reported: 2020-04-24
Rejected by: Paul Wouters (IESG)

Section: 4.1.1

Original Text
-
Note that if the PSK can be used without (EC)DHE, then
non-overlap in the "supported_groups" parameters need not be fatal, 
as it is in the non-PSK case discussed in the previous paragraph.

Corrected Text
--
Note that if the PSK can be used without (EC)DHE, then
non-overlap in the "supported_groups" parameters need not be fatal, 
as it is in the non-PSK case discussed in the previous paragraph, 
because PSK-only key exchange mode does not need supported_groups.

Notes
-
If "the PSK can be used without (EC)DHE", then PSK-only key exchange mode can 
be used, which doesn't require supported_groups. This is perhaps worthy of 
explanation.
 --VERIFIER NOTES-- 
   rejected by WG

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
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] [Errata Rejected] RFC8446 (6124)

[RFC Errata System]

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
Type: Editorial

Reported by: Ben Smyth 
Date Reported: 2020-04-24
Rejected by: Paul Wouters (IESG)

Section: 2

Original Text
-
   In the Key Exchange phase, the client sends the ClientHello  
   (Section 4.1.2) message, which contains a random nonce   
   (ClientHello.random); its offered protocol versions; a list of   
   symmetric cipher/HKDF hash pairs; either a set of Diffie-Hellman key 
   shares (in the "key_share" (Section 4.2.8) extension), a set of  
   pre-shared key labels (in the "pre_shared_key" (Section 4.2.11)  
   extension), or both; and potentially additional extensions.   

Corrected Text
--
   In the Key Exchange phase, the client sends the ClientHello  
   (Section 4.1.2) message, which contains a random nonce   
   (ClientHello.random); its offered protocol versions; a list of   
   symmetric cipher/Hash algorithm pairs; either a set of Diffie-Hellman key
 
   shares (in the "key_share" (Section 4.2.8) extension), a set of  
   pre-shared key labels (in the "pre_shared_key" (Section 4.2.11)  
   extension), or both; and potentially additional extensions.   

or

   In the Key Exchange phase, the client sends the ClientHello  
   (Section 4.1.2) message, which contains a random nonce   
   (ClientHello.random); its offered protocol versions; a list of   
   symmetric cipher/Hash algorithm (to be used with HKDF) pairs; either a set 
of Diffie-Hellman key 
   shares (in the "key_share" (Section 4.2.8) extension), a set of  
   pre-shared key labels (in the "pre_shared_key" (Section 4.2.11)  
   extension), or both; and potentially additional extensions.   

Notes
-

 --VERIFIER NOTES-- 
   rejected by WG

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
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] [Errata Rejected] RFC8446 (6144)

[RFC Errata System]

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
Type: Editorial

Reported by: Ben Smyth 
Date Reported: 2020-04-29
Rejected by: Paul Wouters (IESG)

Section: 4.2.8.

Original Text
-
Upon receipt of this extension in a HelloRetryRequest, the client
MUST verify that...the selected_group field does not
correspond to a group which was provided in the "key_share" extension
in the original ClientHello.

Corrected Text
--
Upon receipt of this extension in a HelloRetryRequest, the client
MUST verify that...a key share was not offered (in the "key_share" 
extension in the original ClientHello) for the group in the 
selected_group field.

Notes
-
The original text requires knowledge of the "key_share" extension and is rather 
hard to read,
the proposed text should be easier to understand.
 --VERIFIER NOTES-- 
   rejected by WG

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
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] [Errata Held for Document Update] RFC8446 (6147)

[RFC Errata System]

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

--
Status: Held for Document Update
Type: Editorial

Reported by: Ben Smyth 
Date Reported: 2020-04-29
Held by: Paul Wouters (IESG)

Section: 4.2.10.

Original Text
-
In order to accept early data, the server MUST have accepted a PSK
cipher suiteIn addition, it MUST verify that the
following values are the same as those associated with the
selected PSK:

...

-  The selected cipher suite

Corrected Text
--


Notes
-
Accepting the "PSK cipher suite" surely implies the PSK is associated with the 
cipher suite, hence, 
"The selected cipher suite" can be dropped.

Paul Wouters(SEC AD): The text was changed a little to solve this issue

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
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] [Errata Rejected] RFC8446 (6143)

[RFC Errata System]

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
Type: Technical

Reported by: Ben Smyth 
Date Reported: 2020-04-29
Rejected by: Paul Wouters (IESG)

Section: 4.2.7

Original Text
-
As of TLS 1.3, servers are permitted to send the "supported_groups"
extension to the client.

Corrected Text
--


Notes
-
It is unclear whether servers are permitted to send the "supported_groups" 
extension to 
the client without solicitation, i.e., when the client does not first send the 
extension to the 
server. Clarification would be useful.
 --VERIFIER NOTES-- 
   rejected by WG

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
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] [Errata Rejected] RFC8446 (6145)

[RFC Errata System]

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
Type: Technical

Reported by: Ben Smyth 
Date Reported: 2020-04-29
Rejected by: Paul Wouters (IESG)

Section: 4.2.10.

Original Text
-
When a PSK is used and early data is allowed for that PSK

Corrected Text
--


Notes
-
I couldn't find restrictions that forbid early data for a PSK. Explaining where 
such restrictions
could exist would be useful. E.g., PSKs might be associated with data that 
forbids early data.
 --VERIFIER NOTES-- 
   rejected by WG

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
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] Re: [Errata Held for Document Update] RFC8446 (6147)

[Martin Thomson]

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 early data 
> requires an exact match on top of it.
>
> On Thu, Oct 17, 2024, 12:21 RFC Errata System  
> wrote:
>> 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
>> 
>> --
>> Status: Held for Document Update
>> Type: Editorial
>> 
>> Reported by: Ben Smyth 
>> Date Reported: 2020-04-29
>> Held by: Paul Wouters (IESG)
>> 
>> Section: 4.2.10.
>> 
>> Original Text
>> -
>> In order to accept early data, the server MUST have accepted a PSK
>> cipher suiteIn addition, it MUST verify that the
>> following values are the same as those associated with the
>> selected PSK:
>> 
>> ...
>> 
>> -  The selected cipher suite
>> 
>> Corrected Text
>> --
>> 
>> 
>> Notes
>> -
>> Accepting the "PSK cipher suite" surely implies the PSK is associated with 
>> the cipher suite, hence, 
>> "The selected cipher suite" can be dropped.
>> 
>> Paul Wouters(SEC AD): The text was changed a little to solve this issue
>> 
>> --
>> RFC8446 (draft-ietf-tls-tls13-28)
>> --
>> Title   : The Transport Layer Security (TLS) Protocol Version 1.3
>> Publication Date: August 2018
>> Author(s)   : E. Rescorla
>> Category: PROPOSED STANDARD
>> 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 mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org

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

[TLS] Re: TLS WG Interim summary (was Re: TLS WG Virtual Interim on FATT Process)

[Sean Turner]

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 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 shape. We obviously have to address how we get formal security 
>> analysis if one is requested but the authors do not have the expertise to 
>> provide one.
>> 
>> Also, draft-ietf-tls-8773bis is mid-process and needs a FATT Liaison so the 
>> chairs are going to work to get one.
>> 
>> Cheers,
>> spt
>> 
>>> On Oct 1, 2024, at 20:15, Sean Turner  wrote:
>>> 
>>> Thanks to all those who participated in the poll. Unfortunately, we 
>>> couldn’t schedule a time where everybody could attend. The following time 
>>> slot had the most people:
>>> 
 Begin forwarded message:
 
 From: IETF Meeting Session Request Tool 
 Subject: interim-2024-tls-02 interim approved
 Date: October 1, 2024 at 20:09:13 EDT
 To: , 
 
 
 An interim meeting for tls has been approved or does not require 
 additional approval.
 A message has been sent to the secretariat requesting the interim be 
 announced.
 
 
 -
 Working Group Name: Transport Layer Security
 Area Name: Security Area
 Session Requester: Sean Turner
 
 Meeting Type: Virtual Meeting
 
 Session 1:
 
 Date: 2024-10-16
 Start Time: 14:00 America/New_York
 Duration: 02:00
 Remote Participation Information: 
 https://meetings.conf.meetecho.com/interim/?group=7627d881-2175-4086-899f-657548e64b52
 Agenda Note: 
 
 
>>> 
>>> I will make sure to send reminders out prior to meeting. We will also 
>>> record this session. And, we plan to have “the plan” out in advance (like a 
>>> week) so that those that can’t make it in person can provide comments.
>>> 
>>> Cheers,
>>> spt
>>> 
 On Sep 23, 2024, at 16:53, Sean Turner  wrote:
 
 Hi! Thanks to all those who have already filled out the poll. I am hoping 
 to close this out by Friday so I will send daily reminders until then.
 
 Cheers,
 spt
 
> On Sep 23, 2024, at 12:05, Sean Turner  wrote:
> 
> The chairs would like to have an interim to review the FATT (Formal 
> Analysis Triage Team) process. We are still working out the proposal, but 
> we would like to get this meeting scheduled to review any feedback / 
> comments once we do post the process. Please fill out the following with 
> your available times if you are interested in attending:
> 
> https://doodle.com/meeting/participate/id/aMoXAp1d
> 
> Thanks,
> Deirdre, Joe, & Sean
 
>>> 
>> 
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
> 

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

[TLS] Re: [Errata Held for Document Update] RFC8446 (6147)

[Paul Wouters]

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 associated with the
selected PSK:

The selected TLS version number

The selected cipher suite

The selected ALPN [RFC7301 ]
protocol, if any
These requirements are a superset of those needed to perform a 1-RTT
handshake using the PSK in question.Future extensions MUST define their
interaction with 0-RTT.


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

Paul




On Thu, Oct 17, 2024 at 6:06 PM Martin Thomson  wrote:

> 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 early data
> > requires an exact match on top of it.
> >
> > On Thu, Oct 17, 2024, 12:21 RFC Errata System 
> wrote:
> >> 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
> >>
> >> --
> >> Status: Held for Document Update
> >> Type: Editorial
> >>
> >> Reported by: Ben Smyth 
> >> Date Reported: 2020-04-29
> >> Held by: Paul Wouters (IESG)
> >>
> >> Section: 4.2.10.
> >>
> >> Original Text
> >> -
> >> In order to accept early data, the server MUST have accepted a PSK
> >> cipher suiteIn addition, it MUST verify that the
> >> following values are the same as those associated with the
> >> selected PSK:
> >>
> >> ...
> >>
> >> -  The selected cipher suite
> >>
> >> Corrected Text
> >> --
> >>
> >>
> >> Notes
> >> -
> >> Accepting the "PSK cipher suite" surely implies the PSK is associated
> with the cipher suite, hence,
> >> "The selected cipher suite" can be dropped.
> >>
> >> Paul Wouters(SEC AD): The text was changed a little to solve this issue
> >>
> >> --
> >> RFC8446 (draft-ietf-tls-tls13-28)
> >> --
> >> Title   : The Transport Layer Security (TLS) Protocol
> Version 1.3
> >> Publication Date: August 2018
> >> Author(s)   : E. Rescorla
> >> Category: PROPOSED STANDARD
> >> 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 mailing list -- tls@ietf.org
> > To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [Errata Held for Document Update] RFC8446 (6147)

[Martin Thomson]

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 document is correct.  The problem is that the erratum is flatly 
incorrect.

It says:
> hence,  "The selected cipher suite" can be dropped.

The notes on the erratum might point out that the text mentioning a "PSK cipher 
suite" was perhaps misleading and has been reworded in the update, but the 
suggestion to drop "The selected cipher suite" is incorrect.

I would still reject the erratum.

___
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

[David Benjamin]

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 WG wants to
make them match the widely deployed one. (Though, of course, of they are
also widely deployed in some other context, we should probably leave them
alone too.)

On Thu, Oct 17, 2024, 08:33 David Benjamin  wrote:

> 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
> think it's worth the churn just to flip this back and forth now. Especially
> as key share prediction is not yet done and widely deployed.
>
> I also agree that making the names inconsistent with each other will just
> confuse people, even if the internal orders are inconsistent.
>
> On Thu, Oct 17, 2024, 08:19 Jan Schaumann  40netmeister@dmarc.ietf.org> wrote:
>
>> 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 name reflects the
>> order."
>>
>> This strikes me as overall much less confusing all
>> around than
>>
>> "One is called , the other is called
>> , because we wanted to have both end in
>> the same string."
>>
>> People choosing will do a substring match ("I want
>> PQC, so... ok, here's one that contains 'MLKEM', let
>> me enable that.").
>>
>> -Jan
>>
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
>
___
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

[David Benjamin]

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
think it's worth the churn just to flip this back and forth now. Especially
as key share prediction is not yet done and widely deployed.

I also agree that making the names inconsistent with each other will just
confuse people, even if the internal orders are inconsistent.

On Thu, Oct 17, 2024, 08:19 Jan Schaumann  wrote:

> 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 name reflects the
> order."
>
> This strikes me as overall much less confusing all
> around than
>
> "One is called , the other is called
> , because we wanted to have both end in
> the same string."
>
> People choosing will do a substring match ("I want
> PQC, so... ok, here's one that contains 'MLKEM', let
> me enable that.").
>
> -Jan
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
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

[Salz, Rich]

* 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 and others, FIPS) might preclude that.

* I don't have a strong opinion about which should go first.

As I said, I think compliance might force our hand.

* Can we please have a separator between them, as in MLKEM768_X25519?

Yes please!

A consistent cipher *name* is probably a good idea. And the soon-to-be-added 
Comment field can say “on the wire it’s reversed see RFC xxx” and that RFC 
could/should explain it.
___
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

[John Mattsson]

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

[Geert Hendrickx]

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


Geert


___
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

[Jan Schaumann]

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 name reflects the
order."

This strikes me as overall much less confusing all
around than

"One is called , the other is called
, because we wanted to have both end in
the same string."

People choosing will do a substring match ("I want
PQC, so... ok, here's one that contains 'MLKEM', let
me enable that.").

-Jan

___
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

[Eric Rescorla]

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 separator between them, as in MLKEM768_X25519?

-Ekr


On Thu, Oct 17, 2024 at 8:18 AM Jan Schaumann  wrote:

> 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 name reflects the
> order."
>
> This strikes me as overall much less confusing all
> around than
>
> "One is called , the other is called
> , because we wanted to have both end in
> the same string."
>
> People choosing will do a substring match ("I want
> PQC, so... ok, here's one that contains 'MLKEM', let
> me enable that.").
>
> -Jan
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] [Errata Rejected] RFC8446 (6136)

[RFC Errata System]

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
Type: Technical

Reported by: Ben Smyth 
Date Reported: 2020-04-28
Rejected by: Paul Wouters (IESG)

Section: 4.1.4

Original Text
-
   Upon receipt of a HelloRetryRequest, the client MUST check the
   legacy_version, legacy_session_id_echo, cipher_suite, and 
   legacy_compression_method as specified in Section 4.1.3 

Corrected Text
--


Notes
-
Section 4.1.3 defines no checks for legacy_version nor legacy_compression_method
 --VERIFIER NOTES-- 
   It does have the listed fields and values it should contain (to check) in 
the previous 4.1.3 section.

--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s)   : E. Rescorla
Category: PROPOSED STANDARD
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] Re: [Errata Rejected] RFC8446 (6136)

[Sean Turner]

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".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6136
> 
> --
> Status: Rejected
> Type: Technical
> 
> Reported by: Ben Smyth 
> Date Reported: 2020-04-28
> Rejected by: Paul Wouters (IESG)
> 
> Section: 4.1.4
> 
> Original Text
> -
>   Upon receipt of a HelloRetryRequest, the client MUST check the
>   legacy_version, legacy_session_id_echo, cipher_suite, and 
>   legacy_compression_method as specified in Section 4.1.3 
> 
> Corrected Text
> --
> 
> 
> Notes
> -
> Section 4.1.3 defines no checks for legacy_version nor 
> legacy_compression_method
> --VERIFIER NOTES-- 
>   It does have the listed fields and values it should contain (to check) in 
> the previous 4.1.3 section.
> 
> --
> RFC8446 (draft-ietf-tls-tls13-28)
> --
> Title   : The Transport Layer Security (TLS) Protocol Version 1.3
> Publication Date: August 2018
> Author(s)   : E. Rescorla
> Category: PROPOSED STANDARD
> 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 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

[Tim Hollebeek]

+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-ecdhe-mlkem-02



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 think 
it's worth the churn just to flip this back and forth now. Especially as key 
share prediction is not yet done and widely deployed.



I also agree that making the names inconsistent with each other will just 
confuse people, even if the internal orders are inconsistent.



On Thu, Oct 17, 2024, 08:19 Jan Schaumann 
mailto:40netmeister@dmarc.ietf.org> > wrote:

Bas Westerbaan mailto:40cloudflare@dmarc.ietf.org> > 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 name reflects the
order."

This strikes me as overall much less confusing all
around than

"One is called , the other is called
, because we wanted to have both end in
the same string."

People choosing will do a substring match ("I want
PQC, so... ok, here's one that contains 'MLKEM', let
me enable that.").

-Jan

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



smime.p7s
Description: S/MIME cryptographic signature
___
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

[Watson Ladd]

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 appears that the requirements that some find 
> important (e.g., for me and others, FIPS) might preclude that.

I don't see why the X25519 hybrid needs to be FIPS. The secp256 hybrid
works now, and then when MLKEM is FIPS p256 will still be there. Is
the concern that p256 might get removed, and the ordering constraint
will still exist?
>
>
>
> * I don't have a strong opinion about which should go first.
>
>
>
> As I said, I think compliance might force our hand.
>
>
>
> * Can we please have a separator between them, as in MLKEM768_X25519?
>
>
>
> Yes please!
>
>
>
> A consistent cipher *name* is probably a good idea. And the soon-to-be-added 
> Comment field can say “on the wire it’s reversed see RFC xxx” and that RFC 
> could/should explain it.
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org



-- 
Astra mortemque praestare gradatim

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