[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
