Re: [TLS] ML-KEM key agreement for TLS 1.3

[Sophie Schmieg <[e-mail]>]

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=
[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>


-- 

Sophie Schmieg | Information Security Engineer | ISE Crypto |
[e-mail]