> There will be an annoyingly large number of options on the PQ side---for > example, for different security levels and for patent avoidance---and > I'd expect a tricky discussion of which options to recommend for TLS.
I'm not sure I buy this premise. Currently there seems to be an overwhelming convergence on ML-KEM768 for this job, with the one exception being ML-KEM1024 being favored by the CNSA 2, but the latter also does not recommend hybrids, leaving us with really only one choice for the PQ hybrid for at least the medium term. If the only reason for revisiting the current choices in recommended curves is an expected large number of PQ options (or even just more than one PQ option), it might make sense to have that discussion first. Where I do see some potential contention is on the question on whether to adopt a primitive level hybrid (such as X-Wing or the generic combiner draft) or use a protocol level hybrid (such as X25519Kyber768Draft00), but this question is independent of the choice of classic or PQ algorithm (with the slight exception of X-Wing, which people have criticized for not allowing for FIPS compliant deployment before ML-KEM has become FIPSified due to the lack of P256, but the discussion here seems not about discouraging the use of X25519 in favor of P256 in general, so this too is orthogonal to the problem at hand). All in all, I see little reason to change the recommendations for the elliptic curve part for a PQ hybrid from what they are now for classical cryptography. On Mon, Jun 10, 2024 at 5:46 AM John Mattsson <john.mattsson= 40ericsson....@dmarc.ietf.org> wrote: > Thanks Björn, > > > > I think that is a very good summary. Regarding security requirements for > ephemeral key exchange in TLS I think it is important to discuss that we > are actually talking about 3 quite different settings. > > > 1. Ephemeral key exchange authenticated with a certificate. > 2. Ephemeral key exchange authenticated with an external PSK. > 3. Ephemeral key exchange authenticated with a resumption PSK. > > > > In 1, the ephemeral key exchange is the only secret input to the Key > derivation. > > In 2, the external PSK, which might have a lifetime of decades is also > used in the key derivation. > > In 3, the resumption PSK, which has a lifetime of maximum a week is also > used in the key derivation. > > I think the security requirements for 1. and 3. might be quite different. > > > > Cheers, > > John Preuß Mattsson > > > > *From: *Björn Haase <bjoern.haase=40endress....@dmarc.ietf.org> > *Date: *Monday, 10 June 2024 at 09:32 > *To: *tls@ietf.org <tls@ietf.org> > *Subject: *[TLS]Re: Curve-popularity data? > > [You don't often get email from bjoern.haase=40endress....@dmarc.ietf.org. > Learn why this is important at > https://aka.ms/LearnAboutSenderIdentification ] > > Hello to all, > > I fear that regarding the "Curve-popularity" data there might be too much > of "opinion" and "company policies" and "government policies" around which > IMHO can be an obstacle for constructive discussion. And it seems again to > be a discussion between Short-Weierstrass curves on the one side and the > modern Montgomery/Edwards curves on the other side. > > I think that for getting forward, we probably best try to get a step back > and try to formulate consensus on the actual requirements behind the > reasonings and establish a clearer picture regarding the system > architectures that people have in mind. > > In my perspective, the "security" space at least has at least 4 dimensions > relevant here: > > - Firstly, the biggest security risk might be that no or worse crypto is > used in an application (e.g. no ephemeral session keys instead of > session-specific DH) because DH is considered to be too costly. > > - The second dimension might be that crypto is poorly implemented and > implementation attacks become feasible. > > - The third dimension is the risk of hardware-side-channels and the risk > of leaked private long-term keys. IMO this issue can only be resolved when > using special hardware components for guarding and protecting the private > keys and mandatory requires secure elements. > > - The fourth dimension is the fear regarding future QC attacks. > > > In addition to these dimensions I believe that we need to consider where > applications need to store their keys. For ephemeral session-key-related > secrets I don't see the immediate use-case of storing the private keys in a > secured hardware (TPM or Secure element). However this (IMHO) should really > be different for all of the private long-term keys used for authenticating > a session (e.g. server certificates). IMO its not only the fact that > hardware elements can better protect the keys but good use of > hardware-chips for authentication secrets also avoid slopply management of > keys! > > Regarding curve popularity (unfortunately) most chipsets that offer > hardware protection are using short-Weierstrass curves, however there are > also newer chipsets which also support Ed25519 or Ed448 but that's > currently not the majority. However this reasoning should (IMO) apply only > to the authentication part of TLS and not regarding the session-key > establishment (and DH). > > Actually in my opinion it is only the third dimension mentioned above in > combination with today's restriction regarding secure-element chipsets from > which an advantage for P-256 or P-384 shows up. > > > In my system picture, we might best optimize future TLS for a distributed > architecture with one or two CPUs for the crypto. One CPU A which manages > the session-key establishment and bulk crypto (the main CPU of the system) > and a second CPU B which handles the protocol parts for authentication > which might come with hardware-level-security and a protected persistent > storage for keys (possibly split off to a TPM or Secure element). > > As a result, I would suggest that regarding key-establishment one might be > better off with promoting the newer and more efficient X25519 and X448 in > combination with PQ-Algorithms for the CPU A part as this might optimize > for the dimensions 1,2 and 4. > > Regarding the algorithms for the CPU B part, we probably should try to > split off the algorithm requirements and run a separate assessment. The > better current support for hardware-security for key storage which is a big > plus for P-256 today for the CPU B parts. > > A big part of the discussion here might be that different people have > different system architectures in mind. > > Yours, > > Björn. > > > > > Mit freundlichen Grüßen | Best Regards > > Dr. Björn Haase > > > Senior Expert Electronics | TGREH Electronics Hardware > > Endress+Hauser Liquid Analysis > > Endress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839 Gerlingen | > Germany > Phone: +49 7156 209 10377 <+49%207156%2020910377> > bjoern.ha...@endress.com | > https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ehla.endress.com%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cc52ff10bc38e47a852ff08dc891f8527%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638536015675508599%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=u%2FQ64ZNBably8ivyhXpqLhQjS%2B0DVONCYxDDijWsPw0%3D&reserved=0 > <http://www.ehla.endress.com/> > > > > Endress+Hauser Conducta GmbH+Co.KG > Amtsgericht Stuttgart HRA 201908 > Sitz der Gesellschaft: Gerlingen > Persönlich haftende Gesellschafterin: > Endress+Hauser Conducta Verwaltungsgesellschaft mbH > Sitz der Gesellschaft: Gerlingen > Amtsgericht Stuttgart HRA 201929 > Geschäftsführer: Dr. Manfred Jagiella > > > Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu > informieren, wenn wir personenbezogene Daten von Ihnen erheben. > Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis ( > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.endress.com%2Fde%2Fcookies-endress%2Bhauser-website&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cc52ff10bc38e47a852ff08dc891f8527%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638536015675521182%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=NzdwMRuFD5VZjcY9Kx1%2FHcjCQ4G5gQ3%2BsPFXL24ussg%3D&reserved=0 > <https://www.endress.com/de/cookies-endress+hauser-website>) nach. > > > > Disclaimer: > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential, proprietary, and/or > privileged material. Any review, retransmission, dissemination or other use > of, or taking of any action in reliance upon, this information by persons > or entities other than the intended recipient is prohibited. If you receive > this in error, please contact the sender and delete the material from any > computer. This e-mail does not constitute a contract offer, a contract > amendment, or an acceptance of a contract offer unless explicitly and > conspicuously designated or stated as such. > > _______________________________________________ > 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 > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | sschm...@google.com
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
