[TLS] Re: [EXT] Re: ML-DSA in TLS

[Andrey Jivsov]

Not sure I understand your point, Watson, but for the environments that
cannot tweak configuration, or otherwise effectively turn on/off
algorithms, a composite signature with a PQ and an ECC algorithm is the
most viable option.

On Fri, Nov 15, 2024 at 3:02 PM Watson Ladd  wrote:

>
>
> On Fri, Nov 15, 2024, 2:59 PM Andrey Jivsov  wrote:
>
>> Classic McEllice team shows that over the last 10 years lattice crypto
>> strength dropped as the equivalence of AES192 to AES128. Will this trend
>> continue?
>>
>> In some deployments there may be a need to turn on a PQ method soon, and
>> keep using, e.g. when configurability is not an option. Also, if a change
>> in configuration is possible at a later time to enable a PQ method, ECC may
>> still be secure.
>>
>> Overall, I think it is safer to deploy a hybrid solution as the main
>> option, and either enable it soon, or later.
>>
>
> If you don't want to depend on being able to switch there is one signature
> algorithm secure if any of the candidates are.
>
>
>> On Fri, Nov 15, 2024 at 11:46 AM Blumenthal, Uri - 0553 - MITLL <
>> u...@ll.mit.edu> wrote:
>>
>>> ZjQcmQRYFpfptBannerEnd
>>>
>>> I happen to think that standalone ML-DSA in TLS is a controversial issue.
>>>
>>>
>>>
>>> And I respectfully disagree. As been pointed out already, you cannot
>>> authenticate tomorrow on somebody else yesterday’s connection.
>>>
>>>
>>>
>>> In practice, PQ authentication is not an immediate issue in a sense of
>>> "record now, decrypt later".
>>>
>>>
>>>
>>> Exactly. Except that my conclusion from this is – no hybrid is
>>> necessary. Either move to PQ, or remain with Classic and keep
>>> observing/studying PQ.
>>>
>>>
>>>
>>> There is also an issue of what signatures in X.509 certs will look like.
>>> Especially in CA certificates, these may favor ML-DSA+ECC v.s. ML-DSA, so
>>> there would need to be support by TLS stack for the hybrid for that reason.
>>>
>>>
>>>
>>> This all is based on the assumption that ML-DSA would fail, but ECC
>>> won’t. I find this highly improbable.
>>>
>> ___
>> 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: Working Group Last Call for ECH SSLKEYLOG

[Stephen Farrell]

Hiya,

On 16/11/2024 00:17, Joseph Salowey wrote:

This is the working group last call for SSLKEYLOGFILE Extension for
Encrypted Client Hello. Please review draft-ietf-tls-ech-keylogfile-01 [1]
and reply to this thread indicating if you think it is ready for
publication or not.  If you do not think it is ready please indicate why.
This call will end on November 30, 2024.


As I said before, I don't think this document should be published.
(I was in the rough then so expect to be again.)

The proposed IANA registry for labels is wrong I think. Changes to
the TLS protocol to create new (or change existing) labels that
would be in this registry need IETF consensus and hence so should
changes to this registry. (Or at least a requirement that the
label maps directly to something with IETF consensus.)

I would hope this wouldn't be published before ECH. (Speaking of
which, can we move that along some?:-)

Cheers,
S.




Thanks,

Joe

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-ech-keylogfile/


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




OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Working Group Last Call for ECH SSLKEYLOG

[Watson Ladd]

A few things jumped out about IANA registries. The first is a silly
process question that might be really ugly to address now (and require
the IESG)

Shouldn't the IANA registry here be made by the
draft-ietf-tls-keylogfile? That would make more sense.

And we don't seem to tell IANA to add the new labels defined here. To
my mind that needs to happen lest IANA not notice they were supposed
to do something we didn't explicitly say in the right format
(deservedly so! We should be really explicit to make their lives and
ours easy).

Substantive issues:

Section 4 I don't think is right. I think we want outer in all cases
because that's easier, There's lots of reasons a negotiation might
fail, and the interpreter of the data might not see this. In fact, how
does e.g. Wireshark know what matches the pcap if we use the
InnerClientHello random? I can see a process logging also logging the
secrets before knowing if success happened.

I hope these comments are useful.

Sincerely,
Watson Ladd


On Fri, Nov 15, 2024 at 4:18 PM Joseph Salowey  wrote:
>
> This is the working group last call for SSLKEYLOGFILE Extension for Encrypted 
> Client Hello. Please review draft-ietf-tls-ech-keylogfile-01 [1] and reply to 
> this thread indicating if you think it is ready for publication or not.  If 
> you do not think it is ready please indicate why.  This call will end on 
> November 30, 2024.
>
> Thanks,
>
> Joe
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-ech-keylogfile/
>
> ___
> 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: [EXT] Re: ML-DSA in TLS

[Watson Ladd]

On Fri, Nov 15, 2024, 3:32 PM Andrey Jivsov  wrote:

> Not sure I understand your point, Watson, but for the environments that
> cannot tweak configuration, or otherwise effectively turn on/off
> algorithms, a composite signature with a PQ and an ECC algorithm is the
> most viable option.
>

Why not hash based signatures?

>
> On Fri, Nov 15, 2024 at 3:02 PM Watson Ladd  wrote:
>
>>
>>
>> On Fri, Nov 15, 2024, 2:59 PM Andrey Jivsov  wrote:
>>
>>> Classic McEllice team shows that over the last 10 years lattice crypto
>>> strength dropped as the equivalence of AES192 to AES128. Will this trend
>>> continue?
>>>
>>> In some deployments there may be a need to turn on a PQ method soon, and
>>> keep using, e.g. when configurability is not an option. Also, if a change
>>> in configuration is possible at a later time to enable a PQ method, ECC may
>>> still be secure.
>>>
>>> Overall, I think it is safer to deploy a hybrid solution as the main
>>> option, and either enable it soon, or later.
>>>
>>
>> If you don't want to depend on being able to switch there is one
>> signature algorithm secure if any of the candidates are.
>>
>>
>>> On Fri, Nov 15, 2024 at 11:46 AM Blumenthal, Uri - 0553 - MITLL <
>>> u...@ll.mit.edu> wrote:
>>>
 ZjQcmQRYFpfptBannerEnd

 I happen to think that standalone ML-DSA in TLS is a controversial
 issue.



 And I respectfully disagree. As been pointed out already, you cannot
 authenticate tomorrow on somebody else yesterday’s connection.



 In practice, PQ authentication is not an immediate issue in a sense of
 "record now, decrypt later".



 Exactly. Except that my conclusion from this is – no hybrid is
 necessary. Either move to PQ, or remain with Classic and keep
 observing/studying PQ.



 There is also an issue of what signatures in X.509 certs will look
 like. Especially in CA certificates, these may favor ML-DSA+ECC v.s.
 ML-DSA, so there would need to be support by TLS stack for the hybrid for
 that reason.



 This all is based on the assumption that ML-DSA would fail, but ECC
 won’t. I find this highly improbable.

>>> ___
>>> 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: ML-DSA in TLS

[Andrey Jivsov]

I am curious why this draft exclusively proposes ML-DSA, instead of
adopting a composite signature approach as outlined in
draft-ounsworth-pq-composite-sigs, at least as an option. For instance,
id-MLDSA87-ECDSA-P384-SHA512 defined in the draft aligns with CNSA 2.0.

Could supporters of the draft elaborate on the rationale to favor or
exclusively offer (?) a standalone ML-DSA? Or, will a hybrid ML-DSA be in
another draft?


On Fri, Nov 15, 2024 at 9:13 AM John Mattsson  wrote:

> >I'm unenthusiastic but don't strongly oppose adoption of this and
>
> >similar drafts, mostly because I think we should try get some WG
>
> >consensus on guidance for when these things may be needed (if ever)
>
> >and what the consequences might be should people deploy 'em in the
>
> >meantime. (By 'em I mean anything with any kind of PQ sig or non
>
> >hybrid PQ key exchange.) That guidance might or might not be in a
>
> >separate document, or be copied into each relevant one.
>
>
>
> More discussion would certainly be welcome. IPSECME is discussing what the
> right solution for hybrid PQC authentication is. The two proposals are
> composite public keys and signatures in a single certificate chain vs. two
> certificate chains. Both approaches have benefits and disadvantages. TLS
> should have the same discussion. Using two certificate chains is already
> possible in TLS with Post-Handshake Certificate-Based Client
> Authentication. Post-Handshake Certificate-Based Server Authentication
> should be added anyway as it is needed for long lasting TLS connections in
> infrastructure.
>
> WebPKI might want to wait but the many infrastructure use cases of TLS,
> DTLS, and QUIC need to migrate very soon. US government new requirement is
> that pure RSASSA, ECDSA, and EdDSA are forbidden from after 2035. European
> countries have similar recommendations/requirements. Country to an earlier
> comment on the list, industry does not like new shiny tools, to the
> contrary, industry loves using existing stuff if possible.
>
> https://csrc.nist.gov/pubs/ir/8547/ipd
>
>
> https://cyber.gouv.fr/sites/default/files/2021/03/anssi-guide-mecanismes_crypto-2.04.pdf
>
> >but don't strongly oppose adoption
>
> Please don’t. TLS is already seen as being behind LAMPS, IPSECME, and
> JOSE. Any further delay would likely end up in a lot of LSs from various
> infrastructure SDOs urging IETF to specify quantum-resistant authentication
> in TLS ;)
>
>
>
> Cheers,
>
> John
>
>
>
> *From: *Stephen Farrell 
> *Date: *Friday, 15 November 2024 at 17:46
> *To: *Bas Westerbaan , tls@ietf.org <
> tls@ietf.org>
> *Subject: *[TLS] Re: ML-DSA in TLS
>
>
>
> On 15/11/2024 10:51, Bas Westerbaan wrote:
> > We have posted a -00.
> >
> >
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tls-westerbaan-mldsa-00&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb8e9b9505c8a47465c1308dd0594fae8%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638672859618372708%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CHrEsED8VIB%2FotGnx3i8Es%2BHyquLY6NZAxAaTz8ANnM%3D&reserved=0
> 
>
> I'm unenthusiastic but don't strongly oppose adoption of this and
> similar drafts, mostly because I think we should try get some WG
> consensus on guidance for when these things may be needed (if ever)
> and what the consequences might be should people deploy 'em in the
> meantime. (By 'em I mean anything with any kind of PQ sig or non
> hybrid PQ key exchange.) That guidance might or might not be in a
> separate document, or be copied into each relevant one.
>
> Cheers,
> S.
> ___
> 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: ML-DSA in TLS

[Watson Ladd]

On Fri, Nov 15, 2024, 9:13 AM John Mattsson  wrote:

> >I'm unenthusiastic but don't strongly oppose adoption of this and
>
> >similar drafts, mostly because I think we should try get some WG
>
> >consensus on guidance for when these things may be needed (if ever)
>
> >and what the consequences might be should people deploy 'em in the
>
> >meantime. (By 'em I mean anything with any kind of PQ sig or non
>
> >hybrid PQ key exchange.) That guidance might or might not be in a
>
> >separate document, or be copied into each relevant one.
>
>
>
> More discussion would certainly be welcome. IPSECME is discussing what the
> right solution for hybrid PQC authentication is. The two proposals are
> composite public keys and signatures in a single certificate chain vs. two
> certificate chains. Both approaches have benefits and disadvantages. TLS
> should have the same discussion. Using two certificate chains is already
> possible in TLS with Post-Handshake Certificate-Based Client
> Authentication. Post-Handshake Certificate-Based Server Authentication
> should be added anyway as it is needed for long lasting TLS connections in
> infrastructure.
>

Authentication is not like encryption. Why do you need two chains vs having
a backup algorithm?

>
>
> WebPKI might want to wait but the many infrastructure use cases of TLS,
> DTLS, and QUIC need to migrate very soon. US government new requirement is
> that pure RSASSA, ECDSA, and EdDSA are forbidden from after 2035. European
> countries have similar recommendations/requirements. Country to an earlier
> comment on the list, industry does not like new shiny tools, to the
> contrary, industry loves using existing stuff if possible.
>
> https://csrc.nist.gov/pubs/ir/8547/ipd
>
>
> https://cyber.gouv.fr/sites/default/files/2021/03/anssi-guide-mecanismes_crypto-2.04.pdf
>
> >but don't strongly oppose adoption
>
> Please don’t. TLS is already seen as being behind LAMPS, IPSECME, and
> JOSE. Any further delay would likely end up in a lot of LSs from various
> infrastructure SDOs urging IETF to specify quantum-resistant authentication
> in TLS ;)
>
>
>
> Cheers,
>
> John
>
>
>
> *From: *Stephen Farrell 
> *Date: *Friday, 15 November 2024 at 17:46
> *To: *Bas Westerbaan , tls@ietf.org <
> tls@ietf.org>
> *Subject: *[TLS] Re: ML-DSA in TLS
>
>
>
> On 15/11/2024 10:51, Bas Westerbaan wrote:
> > We have posted a -00.
> >
> >
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tls-westerbaan-mldsa-00&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb8e9b9505c8a47465c1308dd0594fae8%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638672859618372708%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CHrEsED8VIB%2FotGnx3i8Es%2BHyquLY6NZAxAaTz8ANnM%3D&reserved=0
> 
>
> I'm unenthusiastic but don't strongly oppose adoption of this and
> similar drafts, mostly because I think we should try get some WG
> consensus on guidance for when these things may be needed (if ever)
> and what the consequences might be should people deploy 'em in the
> meantime. (By 'em I mean anything with any kind of PQ sig or non
> hybrid PQ key exchange.) That guidance might or might not be in a
> separate document, or be copied into each relevant one.
>
> Cheers,
> S.
> ___
> 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: ML-DSA in TLS

[Alicja Kario]

On Friday, 15 November 2024 18:38:56 CET, Andrey Jivsov wrote:
I am curious why this draft exclusively proposes ML-DSA, 
instead of adopting a composite signature approach as outlined 
in draft-ounsworth-pq-composite-sigs, at least as an option. For 
instance, id-MLDSA87-ECDSA-P384-SHA512 defined in the draft 
aligns with CNSA 2.0.


Could supporters of the draft elaborate on the rationale to 
favor or exclusively offer (?) a standalone ML-DSA? Or, will a 
hybrid ML-DSA be in another draft?


We will definitely need a second draft with hybrid ML-DSA definitions.

The reason for pure ML-DSA is that for TLS use case, use of hybrids has
limited benefits. OTOH, we can be sure that for use cases like S/MIME
we will want clients that use hybrid algorithms, and we know that reusing
certificates for user authentication is quite common, so we will
need codepoints at the very least for clients. But then there's no point
in limiting it to clients only.

So, the reason for this draft focusing on ML-DSA only is simplicity:
How to use pure ML-DSA is uncotroversial, both in certs and in signatures,
so we can release this standard quickly.

On Fri, Nov 15, 2024 at 9:13 AM John Mattsson 
 wrote:

I'm unenthusiastic but don't strongly oppose adoption of this and



similar drafts, mostly because I think we should try get some WG



consensus on guidance for when these things may be needed (if ever)



and what the consequences might be should people deploy 'em in the



meantime. (By 'em I mean anything with any kind of PQ sig or non



hybrid PQ key exchange.) That guidance might or might not be in a



separate document, or be copied into each relevant one.


 

More discussion would certainly be welcome. IPSECME is 
discussing what the right solution for hybrid PQC authentication 
is. The two proposals are composite public keys and signatures 
in a single certificate chain vs. two certificate chains. Both 
approaches have benefits and disadvantages. TLS should have the 
same discussion. Using two certificate chains is already 
possible in TLS with Post-Handshake Certificate-Based Client 
Authentication. Post-Handshake Certificate-Based Server 
Authentication should be added anyway as it is needed for long 
lasting TLS connections in infrastructure. 



WebPKI might want to wait but the many infrastructure use cases 
of TLS, DTLS, and QUIC need to migrate very soon. US government 
new requirement is that pure RSASSA, ECDSA, and EdDSA are 
forbidden from after 2035. European countries have similar 
recommendations/requirements. Country to an earlier comment on 
the list, industry does not like new shiny tools, to the 
contrary, industry loves using existing stuff if possible.


https://csrc.nist.gov/pubs/ir/8547/ipd

https://cyber.gouv.fr/sites/default/files/2021/03/anssi-guide-mecanismes_crypto-2.04.pdf



but don't strongly oppose adoption


Please don’t. TLS is already seen as being behind LAMPS, 
IPSECME, and JOSE. Any further delay would likely end up in a 
lot of LSs from various infrastructure SDOs urging IETF to 
specify quantum-resistant authentication in TLS ;)


 


Cheers,

John

 


From: Stephen Farrell 
Date: Friday, 15 November 2024 at 17:46
To: Bas Westerbaan , 
tls@ietf.org 

Subject: [TLS] Re: ML-DSA in TLS



On 15/11/2024 10:51, Bas Westerbaan wrote:

We have posted a -00.

https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tls-westerbaan-mldsa-00&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb8e9b9505c8a47465c1308dd0594fae8%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638672859618372708%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CHrEsED8VIB%2FotGnx3i8Es%2BHyquLY6NZAxAaTz8ANnM%3D&reserved=0


I'm unenthusiastic but don't strongly oppose adoption of this and
similar drafts, mostly because I think we should try get some WG
consensus on guidance for when these things may be needed (if ever)
and what the consequences might be should people deploy 'em in the
meantime. (By 'em I mean anything with any kind of PQ sig or non
hybrid PQ key exchange.) That guidance might or might not be in a
separate document, or be copied into each relevant one.

Cheers,
S.



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

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

[TLS] Re: ML-DSA in TLS

[Alicja Kario]

On Friday, 15 November 2024 18:12:28 CET, John Mattsson wrote:

I'm unenthusiastic but don't strongly oppose adoption of this and
similar drafts, mostly because I think we should try get some WG
consensus on guidance for when these things may be needed (if ever)
and what the consequences might be should people deploy 'em in the
meantime. (By 'em I mean anything with any kind of PQ sig or non
hybrid PQ key exchange.) That guidance might or might not be in a
separate document, or be copied into each relevant one.


More discussion would certainly be welcome. IPSECME is 
discussing what the right solution for hybrid PQC authentication 
is. The two proposals are composite public keys and signatures 
in a single certificate chain vs. two certificate chains. Both 
approaches have benefits and disadvantages. TLS should have the 
same discussion. Using two certificate chains is already 
possible in TLS with Post-Handshake Certificate-Based Client 
Authentication. Post-Handshake Certificate-Based Server 
Authentication should be added anyway as it is needed for long 
lasting TLS connections in infrastructure.


No. Please, no.

Hybrids should be part of certificates.
Once we figure out how to do hybrid in X.509, the TLS use case follows.
I'm of the opinion that IPsec is the same. We don't need anything similar
to the hybrid "anything goes" construction that's in IPsec for
the key exchange.

WebPKI might want to wait but the many infrastructure use cases 
of TLS, DTLS, and QUIC need to migrate very soon. US government 
new requirement is that pure RSASSA, ECDSA, and EdDSA are 
forbidden from after 2035. European countries have similar 
recommendations/requirements. Country to an earlier comment on 
the list, industry does not like new shiny tools, to the 
contrary, industry loves using existing stuff if possible.

https://csrc.nist.gov/pubs/ir/8547/ipd
https://cyber.gouv.fr/sites/default/files/2021/03/anssi-guide-mecanismes_crypto-2.04.pdf


but don't strongly oppose adoption
Please don’t. TLS is already seen as being behind LAMPS, 
IPSECME, and JOSE. Any further delay would likely end up in a 
lot of LSs from various infrastructure SDOs urging IETF to 
specify quantum-resistant authentication in TLS ;)


Cheers,
John

From: Stephen Farrell 
Date: Friday, 15 November 2024 at 17:46
To: Bas Westerbaan , 
tls@ietf.org 

Subject: [TLS] Re: ML-DSA in TLS


On 15/11/2024 10:51, Bas Westerbaan wrote:

We have posted a -00.

https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tls-westerbaan-mldsa-00&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb8e9b9505c8a47465c1308dd0594fae8%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638672859618372708%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CHrEsED8VIB%2FotGnx3i8Es%2BHyquLY6NZAxAaTz8ANnM%3D&reserved=0


I'm unenthusiastic but don't strongly oppose adoption of this and
similar drafts, mostly because I think we should try get some WG
consensus on guidance for when these things may be needed (if ever)
and what the consequences might be should people deploy 'em in the
meantime. (By 'em I mean anything with any kind of PQ sig or non
hybrid PQ key exchange.) That guidance might or might not be in a
separate document, or be copied into each relevant one.

Cheers,
S.




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

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

[TLS] Re: ML-DSA in TLS

[Andrey Jivsov]

I happen to think that standalone ML-DSA in TLS is a controversial issue.

In practice, PQ authentication is not an immediate issue in a sense of
"record now, decrypt later". We expect TLS servers to continue to be
configured with RSA key pair (key+cert) and ECDSA key pair. We are talking
about what the 3d key pair should look like.

In years to come TLS servers and clients will continue to negotiate RSA or
ECDSA-based handshakes, as they are today.

Some time in the future, there may be a need to switch to the 3d key pair.
I fail to see what are the advantages of standalone ML-DSA for this use
case.

Is it marginal performance gain, at the expense of security, some years in
the future?

In addition, supporting pure ML-DSA and ML-DSA + ECC has complexity cost,
interoperability is harder, etc.

There is also an issue of what signatures in X.509 certs will look like.
Especially in CA certificates, these may favor ML-DSA+ECC v.s. ML-DSA, so
there would need to be support by TLS stack for the hybrid for that reason.

Overall, it seems more productive to me to focus on ML-DSA hybrid in TLS. I
am not opposed to ML-DSA only, but to me it would be secondary to ML-DSA
hybrid.

On Fri, Nov 15, 2024 at 9:53 AM Alicja Kario  wrote:

> On Friday, 15 November 2024 18:38:56 CET, Andrey Jivsov wrote:
> > I am curious why this draft exclusively proposes ML-DSA,
> > instead of adopting a composite signature approach as outlined
> > in draft-ounsworth-pq-composite-sigs, at least as an option. For
> > instance, id-MLDSA87-ECDSA-P384-SHA512 defined in the draft
> > aligns with CNSA 2.0.
> >
> > Could supporters of the draft elaborate on the rationale to
> > favor or exclusively offer (?) a standalone ML-DSA? Or, will a
> > hybrid ML-DSA be in another draft?
>
> We will definitely need a second draft with hybrid ML-DSA definitions.
>
> The reason for pure ML-DSA is that for TLS use case, use of hybrids has
> limited benefits. OTOH, we can be sure that for use cases like S/MIME
> we will want clients that use hybrid algorithms, and we know that reusing
> certificates for user authentication is quite common, so we will
> need codepoints at the very least for clients. But then there's no point
> in limiting it to clients only.
>
> So, the reason for this draft focusing on ML-DSA only is simplicity:
> How to use pure ML-DSA is uncotroversial, both in certs and in signatures,
> so we can release this standard quickly.
>
> > On Fri, Nov 15, 2024 at 9:13 AM John Mattsson
> >  wrote:
> >>I'm unenthusiastic but don't strongly oppose adoption of this and
> >
> >>similar drafts, mostly because I think we should try get some WG
> >
> >>consensus on guidance for when these things may be needed (if ever)
> >
> >>and what the consequences might be should people deploy 'em in the
> >
> >>meantime. (By 'em I mean anything with any kind of PQ sig or non
> >
> >>hybrid PQ key exchange.) That guidance might or might not be in a
> >
> >>separate document, or be copied into each relevant one.
> >
> >
> >
> > More discussion would certainly be welcome. IPSECME is
> > discussing what the right solution for hybrid PQC authentication
> > is. The two proposals are composite public keys and signatures
> > in a single certificate chain vs. two certificate chains. Both
> > approaches have benefits and disadvantages. TLS should have the
> > same discussion. Using two certificate chains is already
> > possible in TLS with Post-Handshake Certificate-Based Client
> > Authentication. Post-Handshake Certificate-Based Server
> > Authentication should be added anyway as it is needed for long
> > lasting TLS connections in infrastructure.
> >
> >
> > WebPKI might want to wait but the many infrastructure use cases
> > of TLS, DTLS, and QUIC need to migrate very soon. US government
> > new requirement is that pure RSASSA, ECDSA, and EdDSA are
> > forbidden from after 2035. European countries have similar
> > recommendations/requirements. Country to an earlier comment on
> > the list, industry does not like new shiny tools, to the
> > contrary, industry loves using existing stuff if possible.
> >
> > https://csrc.nist.gov/pubs/ir/8547/ipd
> >
> >
> https://cyber.gouv.fr/sites/default/files/2021/03/anssi-guide-mecanismes_crypto-2.04.pdf
> >
> >
> >>but don't strongly oppose adoption
> >
> > Please don’t. TLS is already seen as being behind LAMPS,
> > IPSECME, and JOSE. Any further delay would likely end up in a
> > lot of LSs from various infrastructure SDOs urging IETF to
> > specify quantum-resistant authentication in TLS ;)
> >
> >
> >
> > Cheers,
> >
> > John
> >
> >
> >
> > From: Stephen Farrell 
> > Date: Friday, 15 November 2024 at 17:46
> > To: Bas Westerbaan ,
> > tls@ietf.org 
> > Subject: [TLS] Re: ML-DSA in TLS
> >
> >
> >
> > On 15/11/2024 10:51, Bas Westerbaan wrote:
> >> We have posted a -00.
> >>
> >>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tls-westerbaan-mldsa-00&data=05%7C02%7Cjohn.m

[TLS] Re: ML-DSA in TLS

[Alicja Kario]

On Friday, 15 November 2024 18:33:27 CET, Stephen Farrell wrote:

Hiya,

On 15/11/2024 17:12, John Mattsson wrote:

WebPKI might want to wait but the many infrastructure use cases of
TLS, DTLS, and QUIC need to migrate very soon. US government new
requirement is that pure RSASSA, ECDSA, and EdDSA are forbidden from
after 2035. European countries have similar recommendations/
requirements.


Other than regulatory issues, what technical reasons are there
justifying a "need to migrate very soon"? I don't think we need
to answer that now, but it's something that needs to be considered
when developing guidance as to when these additional new algs might
best be ignored or deployed.


Deploying support in clients takes years, so even if we don't end up
using ML-DSA right away, having clients shipped that are compatible
with servers that do use ML-DSA is beneficial.

The big issue is that we don't know when we will _need_ PQC authentication,
so we want something that at least has a fighting chance against CRQC,
and this is it. Even if WebPKI ends up not using it.

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

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

[TLS] Re: TLS against censorship

[Christian Huitema]

On 11/15/2024 9:57 AM, Raghu Saxena wrote:

Hey Ed,

On 11/16/24 1:08 AM, evasi...@yandex.ru wrote:

Actually, it is not a problem for them, not at all.
As I stated in the message that you did not copy in the quote: they 
would filter out any Hello that has nested InnerHello.
It is pretty automatic solution. As soon as implemented on DPI, this 
feature would not need any configuration or manual intervention.
Only people that upgraded their browser would be punished (not the 
whole population) - they would have to look how to downgrade the 
browser or disable feature.


Well yes, any new TLS extension can be directly blocked by DPI if they 
want. I think practically the best way around such stuff would be to 
use existing TLS stuff which is too mainstream, e.g. an HTTPS proxy.


Ed,

This issue was flagged from the beginning of the SNI/ECH effort. Having 
a specific TLS extension makes the usage of ECH stand out. But on the 
other hand, it is pretty difficult to design an ESNI/ECH extension that 
does not standout, is compatible with standard TLS processing, and is 
not subject to attacks -- like for example replay attacks. Instead of 
trying to have ECH engineered to be discreet, the WG picked a design 
with robust engineering, and then argued that "you do not stand out if 
everybody does it". Suppose that every TLS Client Hello contains an ECH 
extension, whether they want to encrypt the SNI or not. If we had that, 
then your hypothetical censor would have to block every TLS connection, 
and that would be a very hard choice.


The ECH draft specifies a greasing mechanism that achieves exactly that. 
Clients can insert an ECH extension with fake values -- but only the 
client and the front end server know it is fake. The on-path attackers 
cannot tell -- they just see an ECH extension with a bunch of random 
bytes in it, which is not different from an ECH extension with encrypted 
data in it. If they block these packets, they are going to block way 
more that their desired targets.


You assume that the censorship will be deployed before the next browser 
versions are deployed, and that a browser that systematically grease the 
ECH extension would become immediately unusable. But blocking new 
versions of browsers will be very costly for the censor -- users do want 
the security, features and bug fixes of the new versions. We have no 
evidence of that happening yet.


-- Christian Huitema




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

[TLS] Re: ML-DSA in TLS

[Rebecca Guthrie]

I also support WG adoption.

One suggestion in the Introduction:

"ML-DSA [FIPS204] is a post-quantum signature schemes standardised by NIST. It 
is a module-lattice based scheme." -> "ML-DSA is a module-lattice-based digital 
signature algorithm standardised by NIST in [FIPS204]."

And one suggestion in Section 3:

"Note that these are the pure versions and should not be confused with prehash 
variants such as HashML-DSA-44 also defined in [FIPS204]." -> "Note that these 
values represent ML-DSA and not HashML-DSA [FIPS204, Section 5.4]."

Those who read this later who have not been following mailing list discussions 
might not understand what is meant by "pure versions" since the word "pure" is 
not used in FIPS 204- so it is probably best to just call these ML-DSA and 
HashML-DSA. It may also be helpful to include a pointer to the specific section 
in FIPS 204 where HashML-DSA is defined.

Rebecca Guthrie
she/her
Center for Cybersecurity Standards (CCSS)
Cybersecurity Collaboration Center (CCC)
National Security Agency (NSA)

From: John Mattsson 
Sent: Friday, November 15, 2024 9:41 AM
To: Alicja Kario ; Bas Westerbaan 

Cc:  
Subject: [TLS] Re: ML-DSA in TLS

> Very happy to see it.
>
>I'm for workgroup adoption of it.

+1

From: Alicja Kario mailto:hka...@redhat.com>>
Date: Friday, 15 November 2024 at 15:34
To: Bas Westerbaan 
mailto:bas=40cloudflare@dmarc.ietf.org>>
Cc: mailto:tls@ietf.org>>
Subject: [TLS] Re: ML-DSA in TLS
Very happy to see it.

I'm for workgroup adoption of it.

On Friday, 15 November 2024 11:51:31 CET, Bas Westerbaan wrote:
> We have posted a -00.
>
> https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00
>
>
>
> On Wed, Oct 23, 2024 at 7:29 PM Bas Westerbaan 
> mailto:b...@cloudflare.com>> wrote:
> Hi all,
>
> Unless I overlooked something, we don't have a draft out to
> assign a SignatureAlgorithm to ML-DSA for use in TLS.
>
> It's two days past the I-D submission deadline, but I wanted to
> point you to a short draft we put together to fill this gap.
>
> https://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html
>
> So far, I see only one open question: whether to set a non-zero
> context string.
>
> Best,
>
>  Bas
>
>
>

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

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

[TLS] Re: TLS against censorship

[evasilen]

Hi Raghu,
OTTs reading this statement about privacy is probably laughing.
OTTs are collecting the volume of private information - they are the primary 
danger for privacy. ECH would not help even theoretically.
Hence, I do not care about privacy. It is not possible anyway.
I remember a good joke, it was a banner on the street " is hiring in your 
region, resume is not needed".

About your idea to use many DNS names (and probably keys) per IP:UDP.
It looks like it is a burden for censor to trace many DNS names.
Actually, it is not a problem for them, not at all.
As I stated in the message that you did not copy in the quote: they would 
filter out any Hello that has nested InnerHello.
It is pretty automatic solution. As soon as implemented on DPI, this feature 
would not need any configuration or manual intervention.
Only people that upgraded their browser would be punished (not the whole 
population) - they would have to look how to downgrade the browser or disable 
feature.

By the way, InnerHello intersect with interest of many censors, they would 
block it, it would result in the lost hope for privacy too, right?
Eduard
-Original Message-
From: Raghu Saxena  
Sent: Friday, November 15, 2024 5:51 PM
To: evasi...@yandex.ru; tls@ietf.org
Subject: Re: [TLS] TLS against censorship

Dear Ed,

On 11/15/24 4:09 AM, evasi...@yandex.ru wrote:
>
> Hi Experts,
>
> I am not a strong person on encryption, but it is evident for me that 
> “TLS Encrypted Hello”
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-22 has no 
> value in fighting censorship.
>
> Whatever DNS name would be used for “client-facing server”, it is easy 
> for a particular country authority to drop traffic directed to it.
> Because transit traffic to the real content owners (“backend servers”) 
> would not be affected.
>
> It is especially useless to use a special DNS name (like
> cloudflare-ech.com) for “TLS Encrypted Hello” – it is a clear 
> instruction for the country authority on what to drop.
>
It's something I've raised in the past, but I think the general IETF consensus 
(well at least for the TLS WG) is that ECH is designed to improve privacy, not 
necessarily fight censorship. That said, server providers who wish to try and 
get around it, can advertise ECH records with "legit" looking domains, since 
they can be configured to not care about the "Outer SNI" at all. As an example, 
you can check out my website, which hosts several different ECH configs on 
different ports[0]. Depending on which port you try and connect to, your client 
should use a different ECHConfig.

Regards,
Raghu Saxena

[0] https://rfc5746.mywaifu.best:4443/


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

[TLS] Re: ML-DSA in TLS

[John Mattsson]

>I'm unenthusiastic but don't strongly oppose adoption of this and
>similar drafts, mostly because I think we should try get some WG
>consensus on guidance for when these things may be needed (if ever)
>and what the consequences might be should people deploy 'em in the
>meantime. (By 'em I mean anything with any kind of PQ sig or non
>hybrid PQ key exchange.) That guidance might or might not be in a
>separate document, or be copied into each relevant one.

More discussion would certainly be welcome. IPSECME is discussing what the 
right solution for hybrid PQC authentication is. The two proposals are 
composite public keys and signatures in a single certificate chain vs. two 
certificate chains. Both approaches have benefits and disadvantages. TLS should 
have the same discussion. Using two certificate chains is already possible in 
TLS with Post-Handshake Certificate-Based Client Authentication. Post-Handshake 
Certificate-Based Server Authentication should be added anyway as it is needed 
for long lasting TLS connections in infrastructure.

WebPKI might want to wait but the many infrastructure use cases of TLS, DTLS, 
and QUIC need to migrate very soon. US government new requirement is that pure 
RSASSA, ECDSA, and EdDSA are forbidden from after 2035. European countries have 
similar recommendations/requirements. Country to an earlier comment on the 
list, industry does not like new shiny tools, to the contrary, industry loves 
using existing stuff if possible.
https://csrc.nist.gov/pubs/ir/8547/ipd
https://cyber.gouv.fr/sites/default/files/2021/03/anssi-guide-mecanismes_crypto-2.04.pdf

>but don't strongly oppose adoption
Please don’t. TLS is already seen as being behind LAMPS, IPSECME, and JOSE. Any 
further delay would likely end up in a lot of LSs from various infrastructure 
SDOs urging IETF to specify quantum-resistant authentication in TLS ;)

Cheers,
John

From: Stephen Farrell 
Date: Friday, 15 November 2024 at 17:46
To: Bas Westerbaan , tls@ietf.org 

Subject: [TLS] Re: ML-DSA in TLS


On 15/11/2024 10:51, Bas Westerbaan wrote:
> We have posted a -00.
>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tls-westerbaan-mldsa-00&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb8e9b9505c8a47465c1308dd0594fae8%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638672859618372708%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CHrEsED8VIB%2FotGnx3i8Es%2BHyquLY6NZAxAaTz8ANnM%3D&reserved=0

I'm unenthusiastic but don't strongly oppose adoption of this and
similar drafts, mostly because I think we should try get some WG
consensus on guidance for when these things may be needed (if ever)
and what the consequences might be should people deploy 'em in the
meantime. (By 'em I mean anything with any kind of PQ sig or non
hybrid PQ key exchange.) That guidance might or might not be in a
separate document, or be copied into each relevant one.

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

[TLS] Working Group Last Call for ECH SSLKEYLOG

[Joseph Salowey]

This is the working group last call for SSLKEYLOGFILE Extension for
Encrypted Client Hello. Please review draft-ietf-tls-ech-keylogfile-01 [1]
and reply to this thread indicating if you think it is ready for
publication or not.  If you do not think it is ready please indicate why.
This call will end on November 30, 2024.

Thanks,

Joe

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-ech-keylogfile/
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXT] Re: ML-DSA in TLS

[Andrey Jivsov]

Classic McEllice team shows that over the last 10 years lattice crypto
strength dropped as the equivalence of AES192 to AES128. Will this trend
continue?

In some deployments there may be a need to turn on a PQ method soon, and
keep using, e.g. when configurability is not an option. Also, if a change
in configuration is possible at a later time to enable a PQ method, ECC may
still be secure.

Overall, I think it is safer to deploy a hybrid solution as the main
option, and either enable it soon, or later.

On Fri, Nov 15, 2024 at 11:46 AM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> ZjQcmQRYFpfptBannerEnd
>
> I happen to think that standalone ML-DSA in TLS is a controversial issue.
>
>
>
> And I respectfully disagree. As been pointed out already, you cannot
> authenticate tomorrow on somebody else yesterday’s connection.
>
>
>
> In practice, PQ authentication is not an immediate issue in a sense of
> "record now, decrypt later".
>
>
>
> Exactly. Except that my conclusion from this is – no hybrid is necessary.
> Either move to PQ, or remain with Classic and keep observing/studying PQ.
>
>
>
> There is also an issue of what signatures in X.509 certs will look like.
> Especially in CA certificates, these may favor ML-DSA+ECC v.s. ML-DSA, so
> there would need to be support by TLS stack for the hybrid for that reason.
>
>
>
> This all is based on the assumption that ML-DSA would fail, but ECC won’t.
> I find this highly improbable.
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXT] Re: ML-DSA in TLS

[Watson Ladd]

On Fri, Nov 15, 2024, 2:59 PM Andrey Jivsov  wrote:

> Classic McEllice team shows that over the last 10 years lattice crypto
> strength dropped as the equivalence of AES192 to AES128. Will this trend
> continue?
>
> In some deployments there may be a need to turn on a PQ method soon, and
> keep using, e.g. when configurability is not an option. Also, if a change
> in configuration is possible at a later time to enable a PQ method, ECC may
> still be secure.
>
> Overall, I think it is safer to deploy a hybrid solution as the main
> option, and either enable it soon, or later.
>

If you don't want to depend on being able to switch there is one signature
algorithm secure if any of the candidates are.


> On Fri, Nov 15, 2024 at 11:46 AM Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
>
>> ZjQcmQRYFpfptBannerEnd
>>
>> I happen to think that standalone ML-DSA in TLS is a controversial issue.
>>
>>
>>
>> And I respectfully disagree. As been pointed out already, you cannot
>> authenticate tomorrow on somebody else yesterday’s connection.
>>
>>
>>
>> In practice, PQ authentication is not an immediate issue in a sense of
>> "record now, decrypt later".
>>
>>
>>
>> Exactly. Except that my conclusion from this is – no hybrid is necessary.
>> Either move to PQ, or remain with Classic and keep observing/studying PQ.
>>
>>
>>
>> There is also an issue of what signatures in X.509 certs will look like.
>> Especially in CA certificates, these may favor ML-DSA+ECC v.s. ML-DSA, so
>> there would need to be support by TLS stack for the hybrid for that reason.
>>
>>
>>
>> This all is based on the assumption that ML-DSA would fail, but ECC
>> won’t. I find this highly improbable.
>>
> ___
> 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 against censorship

[Yaroslav Rosomakho]

Christian,

I believe the issue that we are currently observing with "blocked ECH" is
specific to how public SNI is constructed. A given CDN uses a certain
pre-defined public name for all ECH enabled resources - hence an inline
filtering party that wants to prevent ECH can match on that specific public
name and presence of ECH extension in ClientHello.

Ed,

I don't think there is much ECH spec can do about this - versatility of
public name construction depends on many internal operational details of
the hosting service.

On top of that, public SNI is used by some intermediaries to perform their
own DNS lookup and replace destination IP. This is often done to optimise
traffic routing by cloud security providers as the closest CDN node from
cloud security provider perspective could be different than the one
resulting from client DNS lookup. It is also a technique to prevent certain
kinds of domain fronting attacks without invasive TLS inspection.
Hence, replacing public SNI with a random string that would not be
resolvable to the correct destination is likely to create another set of
access issues.

Best Regards,
Yaroslav

On Sat, Nov 16, 2024 at 2:12 AM Christian Huitema 
wrote:

>
> On 11/15/2024 9:57 AM, Raghu Saxena wrote:
> > Hey Ed,
> >
> > On 11/16/24 1:08 AM, evasi...@yandex.ru wrote:
> >> Actually, it is not a problem for them, not at all.
> >> As I stated in the message that you did not copy in the quote: they
> >> would filter out any Hello that has nested InnerHello.
> >> It is pretty automatic solution. As soon as implemented on DPI, this
> >> feature would not need any configuration or manual intervention.
> >> Only people that upgraded their browser would be punished (not the
> >> whole population) - they would have to look how to downgrade the
> >> browser or disable feature.
> >
> > Well yes, any new TLS extension can be directly blocked by DPI if they
> > want. I think practically the best way around such stuff would be to
> > use existing TLS stuff which is too mainstream, e.g. an HTTPS proxy.
>
> Ed,
>
> This issue was flagged from the beginning of the SNI/ECH effort. Having
> a specific TLS extension makes the usage of ECH stand out. But on the
> other hand, it is pretty difficult to design an ESNI/ECH extension that
> does not standout, is compatible with standard TLS processing, and is
> not subject to attacks -- like for example replay attacks. Instead of
> trying to have ECH engineered to be discreet, the WG picked a design
> with robust engineering, and then argued that "you do not stand out if
> everybody does it". Suppose that every TLS Client Hello contains an ECH
> extension, whether they want to encrypt the SNI or not. If we had that,
> then your hypothetical censor would have to block every TLS connection,
> and that would be a very hard choice.
>
> The ECH draft specifies a greasing mechanism that achieves exactly that.
> Clients can insert an ECH extension with fake values -- but only the
> client and the front end server know it is fake. The on-path attackers
> cannot tell -- they just see an ECH extension with a bunch of random
> bytes in it, which is not different from an ECH extension with encrypted
> data in it. If they block these packets, they are going to block way
> more that their desired targets.
>
> You assume that the censorship will be deployed before the next browser
> versions are deployed, and that a browser that systematically grease the
> ECH extension would become immediately unusable. But blocking new
> versions of browsers will be very costly for the censor -- users do want
> the security, features and bug fixes of the new versions. We have no
> evidence of that happening yet.
>
> -- Christian Huitema
>
>
>
>
> ___
> 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: Working Group Last Call for ECH SSLKEYLOG

[Yaroslav Rosomakho]

Hello Watson,

On Sat, Nov 16, 2024 at 1:47 AM Watson Ladd  wrote:

> A few things jumped out about IANA registries. The first is a silly
> process question that might be really ugly to address now (and require
> the IESG)
>
> Shouldn't the IANA registry here be made by the
> draft-ietf-tls-keylogfile? That would make more sense.
>

Yes, that would be great but that draft is already way past WGLC to make
such a change.


> And we don't seem to tell IANA to add the new labels defined here. To
> my mind that needs to happen lest IANA not notice they were supposed
> to do something we didn't explicitly say in the right format
> (deservedly so! We should be really explicit to make their lives and
> ours easy).
>

Good point. For simplicity and ease or read labels introduced by this draft
should be added to the "Table 1".


>
> Substantive issues:
>
> Section 4 I don't think is right. I think we want outer in all cases
> because that's easier, There's lots of reasons a negotiation might
> fail, and the interpreter of the data might not see this. In fact, how
> does e.g. Wireshark know what matches the pcap if we use the
> InnerClientHello random? I can see a process logging also logging the
> secrets before knowing if success happened.
>

The problem with outer for all cases is that it would require significant
change to TLS libraries - they would need to keep in memory random from
both inner and outer ClientHellos if SSLKEYLOGFILE enabled. This is a
significant change in logic that might defeat the purpose of SSLKEYLOGFILE
as a troubleshooting feature. Today TLS libraries that support ECH tend to
discard random from outer ClientHello once ECH got negotiated.

Wireshark performs the same thing as a client would to figure out if ECH
was accepted or not - computes transcript with decrypted and "re-inflated"
ClinetHello and compares bytes of ServerHello random (taking into account
potential HRR shenanigans). It then uses random from corresponding
ClientHello - inner if computation matched or outer if it did not.

The presence of ECH_SECRET and ECH_CONFIG on their own does not imply that
ECH was successfully accepted - especially if SSLKEYLOGFILE is generated by
the client side.



>
> I hope these comments are useful.
>

Absolutely! Thank you for constructive comments.


>
> Sincerely,
> Watson Ladd
>


Best Regards,
Yaroslav


>
>
> On Fri, Nov 15, 2024 at 4:18 PM Joseph Salowey  wrote:
> >
> > This is the working group last call for SSLKEYLOGFILE Extension for
> Encrypted Client Hello. Please review draft-ietf-tls-ech-keylogfile-01 [1]
> and reply to this thread indicating if you think it is ready for
> publication or not.  If you do not think it is ready please indicate why.
> This call will end on November 30, 2024.
> >
> > Thanks,
> >
> > Joe
> >
> > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-ech-keylogfile/
> >
> > ___
> > 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 mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Working Group Last Call for ECH SSLKEYLOG

[Christian Huitema]

On 11/15/2024 4:28 PM, Stephen Farrell wrote:


Hiya,

On 16/11/2024 00:17, Joseph Salowey wrote:

This is the working group last call for SSLKEYLOGFILE Extension for
Encrypted Client Hello. Please review 
draft-ietf-tls-ech-keylogfile-01 [1]

and reply to this thread indicating if you think it is ready for
publication or not.  If you do not think it is ready please indicate 
why.

This call will end on November 30, 2024.


As I said before, I don't think this document should be published.
(I was in the rough then so expect to be again.)


Ditto.



The proposed IANA registry for labels is wrong I think. Changes to
the TLS protocol to create new (or change existing) labels that
would be in this registry need IETF consensus and hence so should
changes to this registry. (Or at least a requirement that the
label maps directly to something with IETF consensus.)


Yes. The potential for abuse is quite large. I agree with Stephen that 
it would be better if there was no such registry. And if such a registry 
is somehow created, new entries should require IETF consensus.




I would hope this wouldn't be published before ECH. (Speaking of
which, can we move that along some?:-)


+1


-- Christian Huitema

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

[TLS] Re: TLS against censorship

[Stephen Farrell]

Hiya,

On 16/11/2024 02:48, Yaroslav Rosomakho wrote:


I believe the issue that we are currently observing with "blocked ECH" is
specific to how public SNI is constructed. A given CDN uses a certain
pre-defined public name for all ECH enabled resources - hence an inline
filtering party that wants to prevent ECH can match on that specific public
name and presence of ECH extension in ClientHello.


I think the above is correct... today. I don't think we'll see how
the dynamics of all this plays out until there are many more servers
that have ECH enabled for many more web sites. Between now and then,
we'll see how all the various entities involved act, but hopefully
(from my POV) we'll all stick at it and end up with an overall modest
gain for privacy. The "between now and then" bit requires us to
work to make ECH available for standard web server installs, so I
hope people keep on asking for that feature from those distributing
web servers. (Interestingly, I suspect that having ECH enabled for
many servers with few web sites, might help services hosting many
web sites with their "larger" ECH deployments, but we'll have to
see how things develop.)

Cheers,
S.



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ML-DSA in TLS

[Bas Westerbaan]

We have posted a -00.

https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00



On Wed, Oct 23, 2024 at 7:29 PM Bas Westerbaan  wrote:

> Hi all,
>
> Unless I overlooked something, we don't have a draft out to assign a
> SignatureAlgorithm to ML-DSA for use in TLS.
>
> It's two days past the I-D submission deadline, but I wanted to point you
> to a short draft we put together to fill this gap.
>
> https://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html
>
> So far, I see only one open question: whether to set a non-zero context
> string.
>
> Best,
>
>  Bas
>
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: TLS against censorship

[Raghu Saxena]

Dear Ed,

On 11/15/24 4:09 AM, evasi...@yandex.ru wrote:


Hi Experts,

I am not a strong person on encryption, but it is evident for me that 
“TLS Encrypted Hello” 
https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-22 has no 
value in fighting censorship.


Whatever DNS name would be used for “client-facing server”, it is easy 
for a particular country authority to drop traffic directed to it. 
Because transit traffic to the real content owners (“backend servers”) 
would not be affected.


It is especially useless to use a special DNS name (like 
cloudflare-ech.com) for “TLS Encrypted Hello” – it is a clear 
instruction for the country authority on what to drop.


It's something I've raised in the past, but I think the general IETF 
consensus (well at least for the TLS WG) is that ECH is designed to 
improve privacy, not necessarily fight censorship. That said, server 
providers who wish to try and get around it, can advertise ECH records 
with "legit" looking domains, since they can be configured to not care 
about the "Outer SNI" at all. As an example, you can check out my 
website, which hosts several different ECH configs on different 
ports[0]. Depending on which port you try and connect to, your client 
should use a different ECHConfig.


Regards,
Raghu Saxena

[0] https://rfc5746.mywaifu.best:4443/



OpenPGP_0xA1E21ED06A67D28A.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ML-DSA in TLS

[Alicja Kario]

Very happy to see it.

I'm for workgroup adoption of it.

On Friday, 15 November 2024 11:51:31 CET, Bas Westerbaan wrote:

We have posted a -00.

https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00



On Wed, Oct 23, 2024 at 7:29 PM Bas Westerbaan  wrote:
Hi all,

Unless I overlooked something, we don't have a draft out to 
assign a SignatureAlgorithm to ML-DSA for use in TLS.


It's two days past the I-D submission deadline, but I wanted to 
point you to a short draft we put together to fill this gap.


https://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html

So far, I see only one open question: whether to set a non-zero 
context string.


Best,

 Bas





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

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

[TLS] Re: ML-DSA in TLS

[John Mattsson]

> Very happy to see it.
>
>I'm for workgroup adoption of it.

+1

From: Alicja Kario 
Date: Friday, 15 November 2024 at 15:34
To: Bas Westerbaan 
Cc: 
Subject: [TLS] Re: ML-DSA in TLS
Very happy to see it.

I'm for workgroup adoption of it.

On Friday, 15 November 2024 11:51:31 CET, Bas Westerbaan wrote:
> We have posted a -00.
>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tls-westerbaan-mldsa-00&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C276e1fb11bdd4a94eeac08dd0582a44d%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638672780837605625%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4OzJ0jt2DDTPrknFBI9eC2EqOQLqtWapoTEx29szLp8%3D&reserved=0
>
>
>
> On Wed, Oct 23, 2024 at 7:29 PM Bas Westerbaan  wrote:
> Hi all,
>
> Unless I overlooked something, we don't have a draft out to
> assign a SignatureAlgorithm to ML-DSA for use in TLS.
>
> It's two days past the I-D submission deadline, but I wanted to
> point you to a short draft we put together to fill this gap.
>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbwesterb.github.io%2Ftls-mldsa%2Fdraft-tls-westerbaan-mldsa.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C276e1fb11bdd4a94eeac08dd0582a44d%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638672780837634340%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vLqlLe%2BQy0K2388j%2Fk26sNNihm11ZLbCCRKIQq6WikI%3D&reserved=0
>
> So far, I see only one open question: whether to set a non-zero
> context string.
>
> Best,
>
>  Bas
>
>
>

--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: 
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cz.redhat.com%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C276e1fb11bdd4a94eeac08dd0582a44d%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638672780837657818%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xwueW1KmqxPWybf0yibUwhLjplarQjTk2jGhHQ2UFwA%3D&reserved=0
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

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

[TLS] Re: ML-DSA in TLS

[Russ Housley]

Indeed.  This one should progress quickly.

Russ

> On Nov 15, 2024, at 9:33 AM, Alicja Kario  wrote:
> 
> Very happy to see it.
> 
> I'm for workgroup adoption of it.
> 
> On Friday, 15 November 2024 11:51:31 CET, Bas Westerbaan wrote:
>> We have posted a -00.
>> 
>> https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00
>> 
>> 
>> 
>> On Wed, Oct 23, 2024 at 7:29 PM Bas Westerbaan  wrote:
>> Hi all,
>> 
>> Unless I overlooked something, we don't have a draft out to assign a 
>> SignatureAlgorithm to ML-DSA for use in TLS.
>> 
>> It's two days past the I-D submission deadline, but I wanted to point you to 
>> a short draft we put together to fill this gap.
>> 
>> https://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html
>> 
>> So far, I see only one open question: whether to set a non-zero context 
>> string.
>> 
>> Best,
>> 
>> Bas
>> 
>> 
>> 
> 
> -- 
> Regards,
> Alicja (nee Hubert) Kario
> Principal Quality Engineer, RHEL Crypto team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
> 
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ML-DSA in TLS

[Salz, Rich]

I support adoption.

I agree with the comments John and Rebecca made, should be easy edits to make 
after the -00 is submitted.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ML-DSA in TLS

[Watson Ladd]

On Fri, Nov 15, 2024 at 8:45 AM Stephen Farrell
 wrote:
>
>
>
> On 15/11/2024 10:51, Bas Westerbaan wrote:
> > We have posted a -00.
> >
> > https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00
>
> I'm unenthusiastic but don't strongly oppose adoption of this and
> similar drafts, mostly because I think we should try get some WG
> consensus on guidance for when these things may be needed (if ever)
> and what the consequences might be should people deploy 'em in the
> meantime. (By 'em I mean anything with any kind of PQ sig or non
> hybrid PQ key exchange.) That guidance might or might not be in a
> separate document, or be copied into each relevant one.

What part of "rough consensus and running code" says "wait for
depoloyment until we have even more documents done?"

Personally i think we are going to need something better than ML-DSA
for the webPKI, probably different schemes at each hop.

>
> Cheers,
> S.
>
> ___
> 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: TLS against censorship

[Raghu Saxena]

Hey Ed,

On 11/16/24 1:08 AM, evasi...@yandex.ru wrote:

Actually, it is not a problem for them, not at all.
As I stated in the message that you did not copy in the quote: they would 
filter out any Hello that has nested InnerHello.
It is pretty automatic solution. As soon as implemented on DPI, this feature 
would not need any configuration or manual intervention.
Only people that upgraded their browser would be punished (not the whole 
population) - they would have to look how to downgrade the browser or disable 
feature.


Well yes, any new TLS extension can be directly blocked by DPI if they 
want. I think practically the best way around such stuff would be to use 
existing TLS stuff which is too mainstream, e.g. an HTTPS proxy.


- Raghu



OpenPGP_0xA1E21ED06A67D28A.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ML-DSA in TLS

[Tim Hollebeek]

Because there are other drafts for the other ideas.

 

Standardizing how to do ML-DSA in TLS in no way “favors” it or otherwise 
indicates any sort of exclusivity. There is nothing in the draft that precludes 
other approaches.

 

-Tim

 

From: Andrey Jivsov  
Sent: Friday, November 15, 2024 12:39 PM
To: John Mattsson 
Cc: Bas Westerbaan ; tls@ietf.org
Subject: [TLS] Re: ML-DSA in TLS

 

I am curious why this draft exclusively proposes ML-DSA, instead of adopting a 
composite signature approach as outlined in draft-ounsworth-pq-composite-sigs, 
at least as an option. For instance, id-MLDSA87-ECDSA-P384-SHA512 defined in 
the draft aligns with CNSA 2.0.

Could supporters of the draft elaborate on the rationale to favor or 
exclusively offer (?) a standalone ML-DSA? Or, will a hybrid ML-DSA be in 
another draft?

 

 

On Fri, Nov 15, 2024 at 9:13 AM John Mattsson 
mailto:40ericsson@dmarc.ietf.org> > wrote:

>I'm unenthusiastic but don't strongly oppose adoption of this and

>similar drafts, mostly because I think we should try get some WG

>consensus on guidance for when these things may be needed (if ever)

>and what the consequences might be should people deploy 'em in the

>meantime. (By 'em I mean anything with any kind of PQ sig or non

>hybrid PQ key exchange.) That guidance might or might not be in a

>separate document, or be copied into each relevant one.

 

More discussion would certainly be welcome. IPSECME is discussing what the 
right solution for hybrid PQC authentication is. The two proposals are 
composite public keys and signatures in a single certificate chain vs. two 
certificate chains. Both approaches have benefits and disadvantages. TLS should 
have the same discussion. Using two certificate chains is already possible in 
TLS with Post-Handshake Certificate-Based Client Authentication. Post-Handshake 
Certificate-Based Server Authentication should be added anyway as it is needed 
for long lasting TLS connections in infrastructure. 

WebPKI might want to wait but the many infrastructure use cases of TLS, DTLS, 
and QUIC need to migrate very soon. US government new requirement is that pure 
RSASSA, ECDSA, and EdDSA are forbidden from after 2035. European countries have 
similar recommendations/requirements. Country to an earlier comment on the 
list, industry does not like new shiny tools, to the contrary, industry loves 
using existing stuff if possible.

https://csrc.nist.gov/pubs/ir/8547/ipd

https://cyber.gouv.fr/sites/default/files/2021/03/anssi-guide-mecanismes_crypto-2.04.pdf

>but don't strongly oppose adoption

Please don’t. TLS is already seen as being behind LAMPS, IPSECME, and JOSE. Any 
further delay would likely end up in a lot of LSs from various infrastructure 
SDOs urging IETF to specify quantum-resistant authentication in TLS ;)

 

Cheers,

John

 

From: Stephen Farrell mailto:stephen.farr...@cs.tcd.ie> >
Date: Friday, 15 November 2024 at 17:46
To: Bas Westerbaan mailto:40cloudflare@dmarc.ietf.org> >, tls@ietf.org   
mailto:tls@ietf.org> >
Subject: [TLS] Re: ML-DSA in TLS



On 15/11/2024 10:51, Bas Westerbaan wrote:
> We have posted a -00.
> 
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tls-westerbaan-mldsa-00
>   
> &data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb8e9b9505c8a47465c1308dd0594fae8%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638672859618372708%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CHrEsED8VIB%2FotGnx3i8Es%2BHyquLY6NZAxAaTz8ANnM%3D&reserved=0

I'm unenthusiastic but don't strongly oppose adoption of this and
similar drafts, mostly because I think we should try get some WG
consensus on guidance for when these things may be needed (if ever)
and what the consequences might be should people deploy 'em in the
meantime. (By 'em I mean anything with any kind of PQ sig or non
hybrid PQ key exchange.) That guidance might or might not be in a
separate document, or be copied into each relevant one.

Cheers,
S.

___
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: ML-DSA in TLS

[John Mattsson]

Agree with Rebecca's comments on ML-DSA and HashML-DSA. After discussing ML-DSA 
a lot with developers, I have noticed that after being used with RSA and ECDSA 
where they needed to combine RSA and ECDSA with a hash function, they have a 
hard time to understand that ML-DSA does not need an additional hash function. 
I think it would be good to explain this for many readers.

John

From: Rebecca Guthrie 
Date: Friday, 15 November 2024 at 17:09
To: , Bas Westerbaan 
Cc: John Mattsson , Alicja Kario 
Subject: RE: [TLS] Re: ML-DSA in TLS
I also support WG adoption.

One suggestion in the Introduction:

"ML-DSA [FIPS204] is a post-quantum signature schemes standardised by NIST. It 
is a module-lattice based scheme." -> "ML-DSA is a module-lattice-based digital 
signature algorithm standardised by NIST in [FIPS204]."

And one suggestion in Section 3:

"Note that these are the pure versions and should not be confused with prehash 
variants such as HashML-DSA-44 also defined in [FIPS204]." -> "Note that these 
values represent ML-DSA and not HashML-DSA [FIPS204, Section 5.4]."

Those who read this later who have not been following mailing list discussions 
might not understand what is meant by "pure versions" since the word "pure" is 
not used in FIPS 204- so it is probably best to just call these ML-DSA and 
HashML-DSA. It may also be helpful to include a pointer to the specific section 
in FIPS 204 where HashML-DSA is defined.

Rebecca Guthrie
she/her
Center for Cybersecurity Standards (CCSS)
Cybersecurity Collaboration Center (CCC)
National Security Agency (NSA)

From: John Mattsson 
Sent: Friday, November 15, 2024 9:41 AM
To: Alicja Kario ; Bas Westerbaan 

Cc:  
Subject: [TLS] Re: ML-DSA in TLS

> Very happy to see it.
>
>I'm for workgroup adoption of it.

+1

From: Alicja Kario mailto:hka...@redhat.com>>
Date: Friday, 15 November 2024 at 15:34
To: Bas Westerbaan 
mailto:bas=40cloudflare@dmarc.ietf.org>>
Cc: mailto:tls@ietf.org>>
Subject: [TLS] Re: ML-DSA in TLS
Very happy to see it.

I'm for workgroup adoption of it.

On Friday, 15 November 2024 11:51:31 CET, Bas Westerbaan wrote:
> We have posted a -00.
>
> https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00
>
>
>
> On Wed, Oct 23, 2024 at 7:29 PM Bas Westerbaan 
> mailto:b...@cloudflare.com>> wrote:
> Hi all,
>
> Unless I overlooked something, we don't have a draft out to
> assign a SignatureAlgorithm to ML-DSA for use in TLS.
>
> It's two days past the I-D submission deadline, but I wanted to
> point you to a short draft we put together to fill this gap.
>
> https://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html
>
> So far, I see only one open question: whether to set a non-zero
> context string.
>
> Best,
>
>  Bas
>
>
>

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

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

[TLS] Re: ML-DSA in TLS

[Stephen Farrell]

On 15/11/2024 10:51, Bas Westerbaan wrote:

We have posted a -00.

https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00


I'm unenthusiastic but don't strongly oppose adoption of this and
similar drafts, mostly because I think we should try get some WG
consensus on guidance for when these things may be needed (if ever)
and what the consequences might be should people deploy 'em in the
meantime. (By 'em I mean anything with any kind of PQ sig or non
hybrid PQ key exchange.) That guidance might or might not be in a
separate document, or be copied into each relevant one.

Cheers,
S.



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ML-DSA in TLS

[Stephen Farrell]

Hiya,

On 15/11/2024 17:12, John Mattsson wrote:

WebPKI might want to wait but the many infrastructure use cases of
TLS, DTLS, and QUIC need to migrate very soon. US government new
requirement is that pure RSASSA, ECDSA, and EdDSA are forbidden from
after 2035. European countries have similar recommendations/
requirements. 


Other than regulatory issues, what technical reasons are there
justifying a "need to migrate very soon"? I don't think we need
to answer that now, but it's something that needs to be considered
when developing guidance as to when these additional new algs might
best be ignored or deployed.

Cheers.
S.



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [EXT] Re: ML-DSA in TLS

[Blumenthal, Uri - 0553 - MITLL]

ZjQcmQRYFpfptBannerEnd 

I happen to think that standalone ML-DSA in TLS is a controversial issue. 

And I respectfully disagree. As been pointed out already, you cannot 
authenticate tomorrow on somebody else yesterday’s connection. 



In practice, PQ authentication is not an immediate issue in a sense of "record 
now, decrypt later". 

Exactly. Except that my conclusion from this is – no hybrid is necessary. 
Either move to PQ, or remain with Classic and keep observing/studying PQ. 


There is also an issue of what signatures in X.509 certs will look like. 
Especially in CA certificates, these may favor ML-DSA+ECC v.s. ML-DSA, so there 
would need to be support by TLS stack for the hybrid for that reason. 

This all is based on the assumption that ML-DSA would fail, but ECC won’t. I 
find this highly improbable. 








smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Genart last call review of draft-ietf-tls-rfc8446bis-11

[Susan Hares via Datatracker]

Reviewer: Susan Hares
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-tls-rfc8446bis-??
Reviewer: Susan Hares
Review Date: 2024-11-15
IETF LC End Date: 2024-11-01
IESG Telechat date: Not scheduled for a telechat

Caveat: Prior to reading this, I had not read RFC8446. 

Summary: The author of this draft (Eric Rescorla) should be commented for 
the amazing amount of careful work on this bis draft. 
This draft provides exhaustive details written. 
The draft is carefully written to include everything an implementer needs. 
The appendices are a gold-mine of really useful information. 

Caveat: I do not have the history on RFC8446, and 
I have not implemented TLS 1.2 or 1.3. Take my opinion 
as a casual reader. I suspect the IETF chair is 
familar with this technology. 

Major issues: None 

Minor issues: None - all messages, state transitions, 
and variables seem to be clearly discussed (AFIK) 

Nits/editorial comments:
NIT-1: 
One confusing nit is the usage of ";" in the following locations. 
The definition of ";" according to scholarly writing for the 
usage of (clause-1);(clause-2) is that the clauses are equivalent. 

In the following cases I cannot find this equivalence:

1.1 Section 1. paragraph 3 (or 4) 

Text:/The handshake protocol is designed to resist tampering; an active attacker
  should not be able to force the peers to negotiate different
  parameters than they would if the connection were not under
  attack./

1.2. Section 1, paragraph 4 (or 5) 
Text:/The TLS standard, however, does
   not specify how protocols add security with TLS; how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left to the judgment of the designers and implementors
   of protocols that run on top of TLS. / 

1.3. Section 1.3, paragraph 1, 
Text:/
   *  Static RSA and Diffie-Hellman cipher suites have been removed; all
  public-key based key exchange mechanisms now provide forward
  secrecy./ 

1.4. Section 4.2.7, last paragraph 

Text:/ If the server has a
   group it prefers to the ones in the "key_share" extension but is
   still willing to accept the ClientHello, it SHOULD send
   "supported_groups" to update the client's view of its preferences;
   this extension SHOULD contain all groups the server supports,
   regardless of whether they are currently supported by the client./ 

1.5. Section 4.2.9, paragraph 2, last sentence 

Text:/  Servers SHOULD NOT
   send NewSessionTicket with tickets that are not compatible with the
   advertised modes; however, if a server does so, the impact will just
   be that the client's attempts at resumption fail./

1.6. Section 4.6.1, paragraph 4 (or 5) 

Text:/The latter is a performance optimization: normally, there is no reason to
   expect that different servers covered by a single certificate would
   be able to accept each other's tickets; hence, attempting resumption
   in that case would waste a single-use ticket. /

1.7. Section 5.3, paragraph 1 

text:/ Each sequence number is
   set to zero at the beginning of a connection and whenever the key is
   changed; the first record transmitted under a particular traffic key
   MUST use sequence number 0./ 

1.8. Secxtion 5.4, paragraph 3

Text:/Implementations MUST NOT send Handshake and Alert records that have a 
zero-length
   TLSInnerPlaintext.content; if such a message is received, the
   receiving implementation MUST terminate the connection with an
   "unexpected_message" alert./ 
 
1.9. Section 8 paragraph 3

1.9.1) Text:/ The server MUST ensure that any
   instance of it (be it a machine, a thread, or any other entity within
   the relevant serving infrastructure) would accept 0-RTT for the same
   0-RTT handshake at most once; this limits the number of replays to
   the number of server instances in the deployment./ 

1.9.2) Text:/ The "at most once per
   server instance" guarantee is a minimum requirement; servers SHOULD
   limit 0-RTT replays further when feasible./ 

1.10) Section 8.3, paragraph 4/5

text:/ For clients on the Internet, this
   implies windows on the order of ten seconds to account for errors in
   clocks and variations in measurements; other deployment scenarios may
   have different needs./ 

NIT2: Too many comments in a sentence 

2.1. Section 1.3, paragraph 1

Text:/
   *  Elliptic curve algorithms are now in the base spec, and new
  signature algorithms, such as EdDSA, are included./ 

In my reading of grammar, the first comma is not needed. 
Its inclusion makes the ", such as EdDSA," confusing. 


2.2. Section 4.4.1, paragraph 5 

It may be that you are just missing an "and". 

Text: /
   For 

[TLS] Fwd: New Version Notification for draft-reddy-tls-composite-mldsa-00.txt

[tirumal reddy]

Hi all,

The updated draft
https://datatracker.ietf.org/doc/draft-reddy-tls-composite-mldsa/,
incorporates feedback received from the WG. It outlines how ML-DSA in
combination with traditional algorithms can be utilized for authentication
in TLS 1.3.

Further, comments and suggestions are welcome.

Best Regards,
-Tiru

-- Forwarded message -
From: 
Date: Thu, 14 Nov 2024 at 16:55
Subject: New Version Notification for draft-reddy-tls-composite-mldsa-00.txt
To: Tirumaleswar Reddy.K , John Gray <
john.g...@entrust.com>, Scott Fluhrer , Timothy
Hollebeek 


A new version of Internet-Draft draft-reddy-tls-composite-mldsa-00.txt has
been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name: draft-reddy-tls-composite-mldsa
Revision: 00
Title:Use of Composite ML-DSA in TLS 1.3
Date: 2024-11-14
Group:Individual Submission
Pages:8
URL:
https://www.ietf.org/archive/id/draft-reddy-tls-composite-mldsa-00.txt
Status:   https://datatracker.ietf.org/doc/draft-reddy-tls-composite-mldsa/
HTML:
https://www.ietf.org/archive/id/draft-reddy-tls-composite-mldsa-00.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-reddy-tls-composite-mldsa


Abstract:

   This document specifies how the post-quantum signature scheme ML-DSA
   [FIPS204], in combination with traditional algorithms RSA-
   PKCS#1v1.5,RSA-PSS, ECDSA, Ed25519, and Ed448 can be used for
   authentication in TLS 1.3.  The composite ML-DSA approach is
   beneficial in deployments where operators seek additional protection
   against potential breaks or catastrophic bugs in ML-DSA.



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

[TLS] Re: [EXT] Re: ML-DSA in TLS

[Andrey Jivsov]

On Fri, Nov 15, 2024 at 3:56 PM Watson Ladd  wrote:

> ...
> Why not hash based signatures?
>

 I think that the stateful ones are perfectly suited for certifications in
X.509 certs, but in the TLS handshake this has to be Sphincs+, at 16.2KB
per signature at the AES-192 security level. In addition to size concerns,
it's not allowed in CNSA 2.0. Are vendors considering SPHINCS+ for this
purpose?
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: ML-DSA in TLS

[tirumal reddy]

On Fri, 15 Nov 2024 at 23:10, Andrey Jivsov  wrote:

> I am curious why this draft exclusively proposes ML-DSA, instead of
> adopting a composite signature approach as outlined in
> draft-ounsworth-pq-composite-sigs, at least as an option. For instance,
> id-MLDSA87-ECDSA-P384-SHA512 defined in the draft aligns with CNSA 2.0.
>
> Could supporters of the draft elaborate on the rationale to favor or
> exclusively offer (?) a standalone ML-DSA? Or, will a hybrid ML-DSA be in
> another draft?
>
The hybrid ML-DSA draft (see
https://datatracker.ietf.org/doc/draft-reddy-tls-composite-mldsa/) was
published before the standalone ML-DSA and we published a revised draft to
address the comments from the WG.

-Tiru


> On Fri, Nov 15, 2024 at 9:13 AM John Mattsson  40ericsson@dmarc.ietf.org> wrote:
>
>> >I'm unenthusiastic but don't strongly oppose adoption of this and
>>
>> >similar drafts, mostly because I think we should try get some WG
>>
>> >consensus on guidance for when these things may be needed (if ever)
>>
>> >and what the consequences might be should people deploy 'em in the
>>
>> >meantime. (By 'em I mean anything with any kind of PQ sig or non
>>
>> >hybrid PQ key exchange.) That guidance might or might not be in a
>>
>> >separate document, or be copied into each relevant one.
>>
>>
>>
>> More discussion would certainly be welcome. IPSECME is discussing what
>> the right solution for hybrid PQC authentication is. The two proposals are
>> composite public keys and signatures in a single certificate chain vs. two
>> certificate chains. Both approaches have benefits and disadvantages. TLS
>> should have the same discussion. Using two certificate chains is already
>> possible in TLS with Post-Handshake Certificate-Based Client
>> Authentication. Post-Handshake Certificate-Based Server Authentication
>> should be added anyway as it is needed for long lasting TLS connections in
>> infrastructure.
>>
>> WebPKI might want to wait but the many infrastructure use cases of TLS,
>> DTLS, and QUIC need to migrate very soon. US government new requirement is
>> that pure RSASSA, ECDSA, and EdDSA are forbidden from after 2035. European
>> countries have similar recommendations/requirements. Country to an earlier
>> comment on the list, industry does not like new shiny tools, to the
>> contrary, industry loves using existing stuff if possible.
>>
>> https://csrc.nist.gov/pubs/ir/8547/ipd
>>
>>
>> https://cyber.gouv.fr/sites/default/files/2021/03/anssi-guide-mecanismes_crypto-2.04.pdf
>>
>> >but don't strongly oppose adoption
>>
>> Please don’t. TLS is already seen as being behind LAMPS, IPSECME, and
>> JOSE. Any further delay would likely end up in a lot of LSs from various
>> infrastructure SDOs urging IETF to specify quantum-resistant authentication
>> in TLS ;)
>>
>>
>>
>> Cheers,
>>
>> John
>>
>>
>>
>> *From: *Stephen Farrell 
>> *Date: *Friday, 15 November 2024 at 17:46
>> *To: *Bas Westerbaan , tls@ietf.org
>> 
>> *Subject: *[TLS] Re: ML-DSA in TLS
>>
>>
>>
>> On 15/11/2024 10:51, Bas Westerbaan wrote:
>> > We have posted a -00.
>> >
>> >
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tls-westerbaan-mldsa-00&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb8e9b9505c8a47465c1308dd0594fae8%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638672859618372708%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CHrEsED8VIB%2FotGnx3i8Es%2BHyquLY6NZAxAaTz8ANnM%3D&reserved=0
>> 
>>
>> I'm unenthusiastic but don't strongly oppose adoption of this and
>> similar drafts, mostly because I think we should try get some WG
>> consensus on guidance for when these things may be needed (if ever)
>> and what the consequences might be should people deploy 'em in the
>> meantime. (By 'em I mean anything with any kind of PQ sig or non
>> hybrid PQ key exchange.) That guidance might or might not be in a
>> separate document, or be copied into each relevant one.
>>
>> Cheers,
>> S.
>> ___
>> 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: [EXT] Re: ML-DSA in TLS

[tirumal reddy]

Hybrids are mandatory for protocols like IKEv2 over UDP to handle
fragmentation (traditional key exchange followed by a PQ KEM), see
https://datatracker.ietf.org/doc/draft-kampanakis-ml-kem-ikev2/.

-Tiru

On Sat, 16 Nov 2024 at 11:43, Watson Ladd  wrote:

>
>
> On Fri, Nov 15, 2024, 8:52 PM Andrey Jivsov  wrote:
>
>> On Fri, Nov 15, 2024 at 3:56 PM Watson Ladd 
>> wrote:
>>
>>> ...
>>> Why not hash based signatures?
>>>
>>
>>  I think that the stateful ones are perfectly suited for certifications
>> in X.509 certs, but in the TLS handshake this has to be Sphincs+, at 16.2KB
>> per signature at the AES-192 security level. In addition to size concerns,
>> it's not allowed in CNSA 2.0. Are vendors considering SPHINCS+ for this
>> purpose?
>>
>
> If CNSA 2.0 is the guide why consider hybrids?
>
>> ___
> 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: [EXT] Re: ML-DSA in TLS

[Watson Ladd]

On Fri, Nov 15, 2024, 8:52 PM Andrey Jivsov  wrote:

> On Fri, Nov 15, 2024 at 3:56 PM Watson Ladd  wrote:
>
>> ...
>> Why not hash based signatures?
>>
>
>  I think that the stateful ones are perfectly suited for certifications in
> X.509 certs, but in the TLS handshake this has to be Sphincs+, at 16.2KB
> per signature at the AES-192 security level. In addition to size concerns,
> it's not allowed in CNSA 2.0. Are vendors considering SPHINCS+ for this
> purpose?
>

If CNSA 2.0 is the guide why consider hybrids?

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

[TLS] Fwd: New Version Notification for draft-reddy-tls-slhdsa-00.txt

[tirumal reddy]

Hi all,

The updated draft https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/,
incorporates feedback received from the WG. It specifies how the PQC
signature scheme SLH-DSA can be used for authentication in TLS 1.3.

Further, comments and suggestions are welcome.

Best Regards,
-Tiru

-- Forwarded message -
From: 
Date: Fri, 15 Nov 2024 at 18:12
Subject: New Version Notification for draft-reddy-tls-slhdsa-00.txt
To: Tirumaleswar Reddy.K , John Gray <
john.g...@entrust.com>, Scott Fluhrer , Timothy
Hollebeek 


A new version of Internet-Draft draft-reddy-tls-slhdsa-00.txt has been
successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name: draft-reddy-tls-slhdsa
Revision: 00
Title:Use of SLH-DSA in TLS 1.3
Date: 2024-11-15
Group:Individual Submission
Pages:8
URL:  https://www.ietf.org/archive/id/draft-reddy-tls-slhdsa-00.txt
Status:   https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/
HTML: https://www.ietf.org/archive/id/draft-reddy-tls-slhdsa-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-reddy-tls-slhdsa


Abstract:

   This memo specifies how the post-quantum signature scheme SLH-DSA
   [FIPS205] is used for authentication in TLS 1.3.



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

[TLS] Re: [EXT] Re: ML-DSA in TLS

[tirumal reddy]

On Sat, 16 Nov 2024 at 10:23, Andrey Jivsov  wrote:

> On Fri, Nov 15, 2024 at 3:56 PM Watson Ladd  wrote:
>
>> ...
>> Why not hash based signatures?
>>
>
>  I think that the stateful ones are perfectly suited for certifications in
> X.509 certs, but in the TLS handshake this has to be Sphincs+, at 16.2KB
> per signature at the AES-192 security level. In addition to size concerns,
> it's not allowed in CNSA 2.0. Are vendors considering SPHINCS+ for this
> purpose?
>

Yes, we are considering SPHINCS+ for long-lived TLS sessions in telco
deployments for interfaces where computational costs of signature
generation and validation are minor compared to data transmission and
processing demands of user data. The findings in Amazon

paper

shows that while PQ algorithms increase the TLS 1.3 handshake data size,
their effect on connection performance is minimal for large data transfers,
especially in low-loss networks.

-Tiru


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