[TLS] Weekly github digest (TLS Working Group Drafts)

[Repository Activity Summary Bot]

Issues
--
* tlswg/draft-ietf-tls-esni (+1/-0/💬1)
 1 issues created:
 - Proxy Mode (by taoso)
   https://github.com/tlswg/draft-ietf-tls-esni/issues/626 


 1 issues received 1 new comments:
 - #626 Proxy Mode (1 by richsalz)
   https://github.com/tlswg/draft-ietf-tls-esni/issues/626 





Repositories tracked by this digest:
---
* https://github.com/tlswg/draft-ietf-tls-semistatic-dh
* https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate
* https://github.com/tlswg/draft-ietf-tls-esni
* https://github.com/tlswg/certificate-compression
* https://github.com/tlswg/draft-ietf-tls-external-psk-importer
* https://github.com/tlswg/draft-ietf-tls-ticketrequest
* https://github.com/tlswg/tls13-spec
* https://github.com/tlswg/tls-flags
* https://github.com/tlswg/dtls13-spec
* https://github.com/tlswg/dtls-conn-id
* https://github.com/tlswg/tls-subcerts
* https://github.com/tlswg/oldversions-deprecate
* https://github.com/tlswg/sniencryption
* https://github.com/tlswg/tls-exported-authenticator
* https://github.com/tlswg/draft-ietf-tls-ctls
* https://github.com/tlswg/external-psk-design-team
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: [TLS]Re: [EXTERNAL] Consensus Call: -rfc8446bis PRs #1360

[D. J. Bernstein]

Eric Rescorla writes:
> I do not think we need to make Curve25519 MTI. The purpose of MTIs is to
> provide a minimum baseline for interoperability, and we have that already
> with the existing MTI. That's entirely compatible with most people
> preferring X25519 because they believe it's better than the MTI.

As the list in Appendix A of https://cr.yp.to/papers.html#safecurves
shows, the NSA/NIST standards for the core tasks of ECDH and signatures
keep triggering security failures, for reasons that two of us correctly
predicted many years ago. One can't expect new implementors to figure
out these security issues if they aren't warned.

As for "believe", in some cases we have direct security comparisons: the
"Minerva" attacks and the recent breaks of "5G Subscription Concealed
Identifiers" worked against implementations of the NSA/NIST standards
while failing against implementations of X25519/Ed25519 in the same
software. More broadly, these NSA/NIST security failures keep happening,
even in major ECC implementations: see, e.g., Firefox's announcement
"CVE-2023-6135: NSS susceptible to 'Minerva' attack".

In general, we should be evaluating MTI choices for their real-world
security impact, not just whether they're sufficient to guarantee
interoperability. What would be best for security is to transition away
from the NSA/NIST approach---as most TLS connections have already done
for encryption. The first step in ensuring interoperability for such a
transition is to add another MTI.

---D. J. Bernstein

P.S. People who need FIPS certification should be asking NIST to follow
through on allowing X25519. NIST said in

   
https://web.archive.org/web/20200810165057/https://csrc.nist.gov/projects/cryptographic-module-validation-program/notices

that it would add Curve25519 and Curve448, that X25519 and X448 "will be
considered for inclusion in a subsequent revision to SP 800-56A", and
that "CMVP does not intend to enforce compliance with SP 800-56A until
these revisions are complete". NIST did finally manage to add Ed25519
last year, so progress is possible. In any event, IETF shouldn't be
allowing NIST to control IETF's cryptographic choices.

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

[TLS] Re: [TLS]Re: [EXTERNAL] Consensus Call: -rfc8446bis PRs #1360

[John Mattsson]

Hi,

D. J. Bernstein wrote:
> recent breaks of "5G Subscription Concealed Identifiers"

The paper broke a hobby implementation of 5G which in addition to ignoring the 
mandatory point validation also ignored the mandatory point compression. The 
implementation is not used in any 5G network and would not interop with any 
compliant implementation.

That said, I agree that implementations not doing point validation is a major 
problem. To quote NIST: "Cryptographic standards and guidelines should be 
chosen to minimize the demands on users and implementers as well as the adverse 
consequences of human mistakes and equipment failures". I agree that NIST 
should allow X25519 and X448. Elliptic curve cryptography will be used for a 
long time. Both in hybrids, but also in contrained radio systems where ML-KEM 
is too big or NIKE is required. My company will use EdDSA in hybrid with 
ML-DSA. Not because ECDSA is bad, but because EdDSA is better.

D. J. Bernstein wrote:
>we should be evaluating MTI choices for their real-world security impact
Dan, do you have any concrete example of TLS implementations using P-256 
without point validation? Otherwise the discussion is a bit to general for TLS.

Cheers,
John

From: D. J. Bernstein 
Date: Sunday, 8 September 2024 at 13:23
To: tls@ietf.org 
Subject: [TLS] Re: [TLS]Re: [EXTERNAL] Consensus Call: -rfc8446bis PRs #1360
Eric Rescorla writes:
> I do not think we need to make Curve25519 MTI. The purpose of MTIs is to
> provide a minimum baseline for interoperability, and we have that already
> with the existing MTI. That's entirely compatible with most people
> preferring X25519 because they believe it's better than the MTI.

As the list in Appendix A of 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcr.yp.to%2Fpapers.html%23safecurves&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C81011ca54deb4ae24caf08dccff8a530%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638613914039116785%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Vz6i0fGqyBcFluh8hzLvBp%2BGamSy4iABNnITqyrkjj4%3D&reserved=0
shows, the NSA/NIST standards for the core tasks of ECDH and signatures
keep triggering security failures, for reasons that two of us correctly
predicted many years ago. One can't expect new implementors to figure
out these security issues if they aren't warned.

As for "believe", in some cases we have direct security comparisons: the
"Minerva" attacks and the recent breaks of "5G Subscription Concealed
Identifiers" worked against implementations of the NSA/NIST standards
while failing against implementations of X25519/Ed25519 in the same
software. More broadly, these NSA/NIST security failures keep happening,
even in major ECC implementations: see, e.g., Firefox's announcement
"CVE-2023-6135: NSS susceptible to 'Minerva' attack".

In general, we should be evaluating MTI choices for their real-world
security impact, not just whether they're sufficient to guarantee
interoperability. What would be best for security is to transition away
from the NSA/NIST approach---as most TLS connections have already done
for encryption. The first step in ensuring interoperability for such a
transition is to add another MTI.

---D. J. Bernstein

P.S. People who need FIPS certification should be asking NIST to follow
through on allowing X25519. NIST said in

   
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweb.archive.org%2Fweb%2F20200810165057%2Fhttps%3A%2F%2Fcsrc.nist.gov%2Fprojects%2Fcryptographic-module-validation-program%2Fnotices&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C81011ca54deb4ae24caf08dccff8a530%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638613914039125481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=RXQwxEVUOqhy1V4h9DTkFhEtNByzTn6rCOuRiWdOaT4%3D&reserved=0

that it would add Curve25519 and Curve448, that X25519 and X448 "will be
considered for inclusion in a subsequent revision to SP 800-56A", and
that "CMVP does not intend to enforce compliance with SP 800-56A until
these revisions are complete". NIST did finally manage to add Ed25519
last year, so progress is possible. In any event, IETF shouldn't be
allowing NIST to control IETF's cryptographic choices.

___
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]Re: [EXTERNAL] Consensus Call: -rfc8446bis PRs #1360

[Watson Ladd]

On Sun, Sep 8, 2024, 9:41 AM John Mattsson  wrote:

> Hi,
>
>
> D. J. Bernstein wrote:
>
> > recent breaks of "5G Subscription Concealed Identifiers"
>
>
>
> The paper broke a hobby implementation of 5G which in addition to
> ignoring the mandatory point validation also ignored the mandatory point
> compression. The implementation is not used in any 5G network and would not
> interop with any compliant implementation.
>
>
>
> That said, I agree that implementations not doing point validation is a
> major problem. To quote NIST: "Cryptographic standards and guidelines
> should be chosen to minimize the demands on users and implementers as
> well as the adverse consequences of human mistakes and equipment failures".
> I agree that NIST should allow X25519 and X448. Elliptic curve cryptography
> will be used for a long time. Both in hybrids, but also in contrained radio
> systems where ML-KEM is too big or NIKE is required. My company will use
> EdDSA in hybrid with ML-DSA. Not because ECDSA is bad, but because EdDSA is
> better.
>
>
>
> D. J. Bernstein wrote:
> >we should be evaluating MTI choices for their real-world security impact
>
> Dan, do you have any concrete example of TLS implementations using P-256
> without point validation? Otherwise the discussion is a bit to general for
> TLS.
>

Yes: several embedded stacks and browsers had issues in 2014. I know
because I found the issues.

>
>
> Cheers,
>
> John
>
>
>
> *From: *D. J. Bernstein 
> *Date: *Sunday, 8 September 2024 at 13:23
> *To: *tls@ietf.org 
> *Subject: *[TLS] Re: [TLS]Re: [EXTERNAL] Consensus Call: -rfc8446bis PRs
> #1360
>
> Eric Rescorla writes:
> > I do not think we need to make Curve25519 MTI. The purpose of MTIs is to
> > provide a minimum baseline for interoperability, and we have that already
> > with the existing MTI. That's entirely compatible with most people
> > preferring X25519 because they believe it's better than the MTI.
>
> As the list in Appendix A of
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcr.yp.to%2Fpapers.html%23safecurves&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C81011ca54deb4ae24caf08dccff8a530%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638613914039116785%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Vz6i0fGqyBcFluh8hzLvBp%2BGamSy4iABNnITqyrkjj4%3D&reserved=0
> 
> shows, the NSA/NIST standards for the core tasks of ECDH and signatures
> keep triggering security failures, for reasons that two of us correctly
> predicted many years ago. One can't expect new implementors to figure
> out these security issues if they aren't warned.
>
> As for "believe", in some cases we have direct security comparisons: the
> "Minerva" attacks and the recent breaks of "5G Subscription Concealed
> Identifiers" worked against implementations of the NSA/NIST standards
> while failing against implementations of X25519/Ed25519 in the same
> software. More broadly, these NSA/NIST security failures keep happening,
> even in major ECC implementations: see, e.g., Firefox's announcement
> "CVE-2023-6135: NSS susceptible to 'Minerva' attack".
>
> In general, we should be evaluating MTI choices for their real-world
> security impact, not just whether they're sufficient to guarantee
> interoperability. What would be best for security is to transition away
> from the NSA/NIST approach---as most TLS connections have already done
> for encryption. The first step in ensuring interoperability for such a
> transition is to add another MTI.
>
> ---D. J. Bernstein
>
> P.S. People who need FIPS certification should be asking NIST to follow
> through on allowing X25519. NIST said in
>
>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweb.archive.org%2Fweb%2F20200810165057%2Fhttps%3A%2F%2Fcsrc.nist.gov%2Fprojects%2Fcryptographic-module-validation-program%2Fnotices&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C81011ca54deb4ae24caf08dccff8a530%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638613914039125481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=RXQwxEVUOqhy1V4h9DTkFhEtNByzTn6rCOuRiWdOaT4%3D&reserved=0
> 
>
> that it would add Curve25519 and Curve448, that X25519 and X448 "will be
> considered for inclusion in a subsequent revision to SP 800-56A", and
> that "CMVP does not intend to enforce compliance with SP 800-56A until
> these revisions are complete". NIST did finally manage to add Ed25519
> last year, so progress is possible. In any event, IETF shouldn't be
> allowing NIST to control IETF's cryptographic choices.
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
> ___
> TLS mailin

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and P-384

[kris]

Hello,

I'm sorry, possibly I've missed some emails.
If there is an interest I propose we add it to existing draft, publish version 
-03 and request a code point.
The repo is here:
https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem

Feel free to open PR

Cheers,
Kris


From: Alicja Kario 
Sent: Saturday, September 7, 2024 12:39:30 AM
To: kris; tls@ietf.org
Subject: draft-kwiatkowski-tls-ecdhe-mlkem and P-384

Hello,

What's the situation with other groups for TLS 1.3?
Specifically, are there any plans to specify SecP384r1MLKEM1024?

As mentioned in multiple emails already, high security system
already have a strict requirement to use P-384 curve exclusively.
Similarly, for post-quantum resistance they will be required
to use ML-KEM-1024.

Will you add it to the draft, or should we start work on a
separate one that defines those hybrid algorithms?
--
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: [EXT] Re: draft-kwiatkowski-tls-ecdhe-mlkem and P-384

[Blumenthal, Uri - 0553 - MITLL]

If we do hybrid at all - it makes perfect sense then to specify ECDHE over P-384 and ML-KEM-1024. Thx—Regards,UriSecure Resilient Systems and TechnologiesMIT Lincoln LaboratoryOn Sep 8, 2024, at 20:06, kris  wrote:
Hello, I'm sorry, possibly I've missed some emails. If there is an interest I propose we add it to existing draft, publish version -03 and request a code point. The repo is here: https: //github. com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem



ZjQcmQRYFpfptBannerStart




  

  
	This Message Is From an External Sender
  
  
This message came from outside the Laboratory.
  



 
  


ZjQcmQRYFpfptBannerEnd


















Hello,

I'm sorry, possibly I've missed some emails.
If there is an interest I propose we add it to existing draft, publish version -03 and request a code point.
The repo is here:
https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem

Feel free to open PR

Cheers,
Kris


From: Alicja Kario 
Sent: Saturday, September 7, 2024 12:39:30 AM
To: kris; tls@ietf.org
Subject: draft-kwiatkowski-tls-ecdhe-mlkem and P-384
 



Hello,

What's the situation with other groups for TLS 1.3?
Specifically, are there any plans to specify SecP384r1MLKEM1024?

As mentioned in multiple emails already, high security system
already have a strict requirement to use P-384 curve exclusively.
Similarly, for post-quantum resistance they will be required
to use ML-KEM-1024.

Will you add it to the draft, or should we start work on a
separate one that defines those hybrid algorithms?
-- 
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.orgTo 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: [TLS]Re: [EXTERNAL] Consensus Call: -rfc8446bis PRs #1360

[D. J. Bernstein]

John Mattsson writes:
> ignoring the mandatory point validation

Exactly! That's how the real world works. The NSA/NIST approach fills
ECDH and signatures with traps for the implementors; implementors fall
into the traps; the NSA/NIST responses sound like "This security failure
is _your_ fault! Read Section 5.6.2.2.2.X.Y.Z.Z.Y of the documentation!"

Actual quote: "NIST is not aware of any vulnerabilities to attacks on
these curves when they are implemented correctly and used as described
in NIST standards and guidelines." Similar earlier quote from NSA: "We
are unaware of any weaknesses in the DSS or in the DES when properly
implemented and used for the purposes for which they both are designed."

It's much more robust to tell implementors "Use X25519" and "Use
Ed25519". We have a detailed analysis of how this reduces security
risks. We also have real-world security observations following the
predicted patterns. Of course, adding X25519 as MTI is just one step
towards telling people not to touch the NSA-supplied footgun, but it's
better than saying "Everything is fine, no action needed".

> Dan, do you have any concrete example of TLS implementations using
> P-256 without point validation?

Yes. I already pointed to the list of security failures in Appendix A of
https://cr.yp.to/papers.html#safecurves; some of the failures listed
there are point-validation failures in TLS implementations.

Furthermore, some of the other examples in the list are security
failures in TLS implementations other than point-validation failures.
See, e.g., the Firefox "CVE-2023-6135: NSS susceptible to 'Minerva'
attack" announcement that I mentioned before.

Does anyone know whether NIST claims that the NSA/NIST curves weren't
"implemented correctly" in Firefox? Or that CVE-2023-6135 wasn't a
vulnerability? Has there been _any_ response? "Everything is fine"?

It's not as if people implementing NSA/NIST curves for TLS are in some
radically different situation from people implementing NSA/NIST curves
for other environments. The full spectrum of implementation failures is
a bunch of dead canaries in the coal mine; asking "Did any miners die
yet?" is the wrong question. We should be proactive about security.

---D. J. Bernstein

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