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
