Good points. I've included these notes in the GitHub tracking issue, and will leave the document as-is for now.
On Thu, Mar 14, 2024, 3:41 PM Sophie Schmieg <sschm...@google.com> wrote: > 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 <david.cooper= > 40nist....@dmarc.ietf.org> 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
