[TLS]Re: Discussions on Trust Anchor Negotiation at IETF 120
Ahead of the meeting tomorrow, I want to highlight some of the questions > which I think we need to find and agree on answers for: > > - What are the problems that we solving? > > - Who are we solving these problems for? Browsers or everyone? > > - Are we proposing a hard requirement on this negotiation mechanism for > anyone wanting to do fully PQ TLS? > > - Can the proposed mechanism be enabled by default in TLS Libraries without > requiring application changes? > > - Can the proposed mechanism support use in a private PKI? How about in a > private PKI that runs over the public Internet (in the now-classic zero-trust > networking model)? > > - What is the long-term vision for TLS and the WebPKI? Are we moving > forward together or fragmenting? > > - How do the proposed mechanisms affect TLS Client Hello fingerprinting or > other tracking vectors? > > - How would the proposed system work in practice? What happens when > actors follow their own interests rather than the requirements of RFCs? > > - Are less popular clients incentivized to lie in their Trust Expressions > about > which root stores they have? The history of browser HTTP User Agent > spoofing [1] highlights how minority clients are forced to spoof the signals > of > other browsers to maximize site compatibility (even though it violates > protocol requirements). > > - How would versioning root programs work in practice when security > requirements change? If the same root CAs are in version N and version > N+1 of a root store and version N+1 adopts a stricter security policy - > can these root CAs still issue certificates for version N? > > - What are the consequences of making it easier to establish new root > programs? For governments that have previously tried to build domestic > root programs, would solve some of the problems they faced and encourage > them to try again? > > Ultimately, these are two complex drafts which propose substantial > changes to TLS and the WebPKI. Besides evaluating the technical details > in the draft themselves, we also have to tackle the nitty gritty > operational questions about how a new system would work in practice—in > particular, considering the incentives of the stakeholders to adopt the > system and or to deliberately deviate from the intended protocol for > self-benefit. > > Finally, in any proposal which alters the power dynamics of a system, > there will be difficult questions of a political nature, especially when > the system in question is depended upon by billions of people. > > Naturally, good people will often disagree on the nuances of these > complex topics. However, we owe it to each other to communicate > constructively, arrive at a shared understanding and find a path > forwards that as much of the community as possible can support. > > Best, > > Dennis > > > [1] https://en.wikipedia.org/wiki/User-Agent_header#User_agent_spoofing > > > ___ > 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 > -- 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
[TLS]Re: Curve-popularity data?
ps 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
[TLS]Re: Curve-popularity data?
Eliminating P256 will not be possible, primarily due to FIPS 140 compliance concerns. From what I have heard from NIST, there are no current plans on adding X25519 to the NIST approved curves, mostly in order to encourage people to transition to PQC instead of ECC. From that point of view, I would prefer a P256+PQ hybrid. >From the security point of view I do not have a strong preference between the two curves, given that P256 has closed formulas these days the implementation benefits are on par, and for TLS cofactors do thankfully not matter. I vaguely prefer P256 just for the odd cases where they do matter. On Fri, Jun 7, 2024 at 11:40 AM D. J. Bernstein wrote: > Eric Rescorla writes: > > I'm struggling to understand what people think is at stake here. > > The WG will soon be faced with decisions regarding which curve+PQ > hybrids to recommend for TLS. Regarding the curve-choice part of that, > some context factors that have been raised (such as interoperability and > regulation) are starting with facts that are different in the hybrid > context and the pure-curve context, and some technical considerations > also vary (e.g., the byte cost of sending two shares rather than one is > more of an issue when each share is curve+PQ than without PQ), while > many other technical considerations are shared between the two contexts. > > Primarily because of the software-security advantages of X25519 over > P-256, I would like to see TLS, and the ecosystem more broadly, moving > towards eliminating P-256 in both contexts in favor of X25519. Getting > X25519 widely deployed in TLS was already a multi-year project; further > steps that would be helpful in the pure-curve context would be WG > decisions to (1) make X25519 mandatory and then (2) make P-256 optional. > The hybrid context will start with the question of what to recommend (I > presume the WG will wait for PQ support in many more TLS stacks before > making PQ mandatory), and in that context I think it'll be best for the > WG to recommend X25519+PQ and not P-256+PQ. > > Meanwhile some arguments have been raised aiming at the opposite > conclusion for hybrids, so it's good to figure out the reasons for the > different conclusions. Overall I see the WG as being in a fact-finding > phase regarding the underlying issues. I've found it very interesting to > see the data points and considerations that people have posted, and for > at least some issues there's progress towards a shared understanding > that will help the WG make its curve decisions. > > ---D. J. Bernstein > > _______ > 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
Re: [TLS] ML-KEM key agreement for TLS 1.3
There was a push to change the parsing logic for ML-KEM public keys to never fail, by silently reducing, without changing the hash of the public key. I am not sure if NIST ended up adopting that change for their final standard (I hope they did, I think it's the best way to handle this problem), which would mean that any appropriately sized binary string is a valid ML-KEM public key. For ciphertexts, this property is already the case, due to the compression that is applied in ML-KEM. If NIST incorporated this change, there would be no way for the ML-KEM based key agreement to fail explicitly, any failure would result in an implicit rejection. In the end, this seems to be the same as with elliptic curves as is as well, point-not-on-curve checks can result in an explicit rejection of a keyshare (for the curves where it can occur), and manipulation of the keyshare (by an attacker or some accidental bit flip that somehow was not caught) would result in an implicit rejection here as well, with server and client computing a different shared secret. The only new possible error path I see is due to random decryption failure of a KEM, but given the cryptographically low chance, I'm not certain if this failure needs special handling in any case, and shouldn't be treated the same as a corrupted key share. After all, they are so unlikely that "cosmic rays flipped all the right bits for QUIC error correction to not notice" is far more likely to result in a decryption error, so treating it the same as a decryption failure due to a corrupted ciphertext seems fine to me. On Thu, Mar 14, 2024 at 11:43 AM David A. Cooper wrote: > I do not believe that "decode_error" would be the correct alert. As the > text currently says: > > *Failures* Some post-quantum key exchange algorithms, including ML-KEM, > have non-zero probability of failure, meaning two honest parties may derive > different shared secrets. This would cause a handshake failure. ML-KEM has > a cryptographically small failure rate; implementers should be aware of the > potential of handshake failure. Clients can retry if a failure is > encountered. > > At least in the case of ML-KEM, decapsulation failures are implicit. As > noted in the text above, the parties would derive different shared secrets > (but they wouldn't know it). So, the client would not know that > decapsulation failed, it would just be unable to decrypt the encrypted > extensions, certificate, etc. The client would have no way of knowing > whether this happened because of an ML-KEM decapsulation failure (extremely > unlikely) or because some data was changed in transit (much more likely). > > Given how small the ML-KEM decapsulation failure rate is (2^-139 or less), > I wouldn't be surprised if random bit flips in transit that aren't caught > by a CRC or other check are more likely than ML-KEM decapsulation failures. > Since the two are indistinguishable to the client, the client would have to > handle them in the same way. So, I would suggest either omitting this > paragraph or just note that a decapsulation failure would be > indistinguishable from a scenario in which some data was changed in > transit, and so would be handled in the same way. > > On 3/13/24 7:08 PM, Deirdre Connolly wrote: > > 4. In the Discussion section (on github), does the portion on failures >> need to contain more information about how a failure should be handled in >> TLS? Should a decrypt_error alert be sent? > > > Oh very good point, DH doesn't usually fail like this; either because of > fundamental (incredibly unlikely) decapsulation failure rates, or just a > bug, this is good to handle, and we should probably update -hybrid-design > to match. I've tracked this in this GitHub issue > <https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/issues/1> > for now. For my own sake, here's the `decode_error` defintion from RFC > 8446: > > decode_error: A message could not be decoded because some field was > > out of the specified range or the length of the message was > > incorrect. This alert is used for errors where the message does > > not conform to the formal protocol syntax. This alert should > > never be observed in communication between proper implementations, > > except when messages were corrupted in the network. > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | sschm...@google.com ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?
I very much appreciate having a concrete hybrid scheme that is intentionally not generic. This avoids the explosion of ciphertext suites that would otherwise occur, and allows for better compatibility of libraries. Fixing the key sizes to ML-KEM 768 and X25519 is aligned with our preferred choices as well, and further increases interoperability. On Thu, Jan 11, 2024 at 9:31 AM Salz, Rich wrote: > I'm going to echo Bas to highlight that X-Wing is not generic to any > IND-CCA KEM, it is a particular primitive construction based on the > internal construction of ML-KEM in particular: > > > > I don’t think it’s our place to try to shoe-horn everything into one > construct. Particularly when we are in the experimentation phase of things. > > > > If people want to have ML-KEM as a material in their composites, it sounds > like they might want to learn from X-Wing, but not try to chop them to fit > into that one keyhole, as it were. > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | sschm...@google.com ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?
> > On 8 Nov 2023, at 8:34, Loganaden Velvindron wrote: > > > > I support moving forward with hybrids as a proactively safe deployment > > option. I think that supporting > > only Kyber for KEX is not enough. It would make sense to have more options. > > > > Google uses NTRU HRSS internally: > > https://cloud.google.com/blog/products/identity-security/why-google-now-uses-post-quantum-cryptography-for-internal-comms > > > > If Google decides to use this externally, how easy would it be to get > > a codepoint for TLS ? > As easy as writing it up in a stable document (may or may not be an Internet-draft) and asking IANA for a code point assignment. > > It can be done in days, if needed. > > Yoav Just to clarify a few things about our internal usage of NTRU-HRSS: This is for historic reasons. Our stated intention is to move to Kyber once NIST releases the standard, see e.g. my talk at PQCrypto [1], where I go into some detail on this topic. Long story short, we had to choose a candidate well before even NIST's round 3 announcement, and haven't changed since changing a ciphersuite, while relatively straightforward is not free, so we would like to avoid doing it twice in a year. The only security consideration that went into the decision for NTRU was that we wanted to use a structured lattice scheme, with NTRU being chosen for non-security related criteria that have since materially changed. I do not think it makes a lot of sense to have multiple schemes based on structured lattices in TLS, and Kyber is in my opinion the superior algorithm. [1] https://www.youtube.com/watch?v=8PYYM3G7_GY -- ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
