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

[Deirdre Connolly <[e-mail]>]

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 <[e-mail]> 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=
> [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]
>
>