I tend to agree with everyone else here, but to offer another viewpoint for consideration:
What's the implementer guidance on how to implement this, if the draft
is silent on this topic? Is this "undefined behaviour"? Would it help
to say that the handshake MUST fail in this situation, rather than imply
anything about retry?
Otherwise, depending on choice of undefined behaviour, you could
actually get a successful handshake. I don't think that's what you had
in mind, since you said this will lead to a handshake failure. But if
the draft is silent on this, anything could happen. So maybe simply
saying that this MUST lead to a handshake failure is worth doing,
otherwise it won't necessarily lead to a failure as you suggest.
To see what I mean, consider an implementation that converts from a
low-level MLKEM library (that do return the potential FAIL case) to a
TLS wrapper that doesn't handle failure:
void derive_secret(char *secret, size_t len)
{
bool ok;
char tmp[SZ];
memset(tmp, 42, SZ);
ok = mlkem(tmp); /* won't touch tmp buffer on !ok */
memcpy (secret, tmp, SZ);
}
On MLKEM failure, and if the two peers used similar code, this would end
up using an all-42 shared secret, and the handshake may succeed. Unless
I'm missing something else here?
/Simon
Eric Rescorla <e...@rtfm.com> writes:
> Hi folks,
>
> I see that the hybrid doc continues to have this text:
>
> *Failures.* Some post-quantum key exchange algorithms, including ML-KEM [
> NIST-FIPS-203
> <https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-16.html#NIST-FIPS-203>
> ], 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; if other algorithms are
> used, implementers should be aware of the potential of handshake failure.
> Clients MAY retry if a failure is encountered.
>
> There was extensive discussion about this for the pure ML-KEM draft, and my
> sense was the sentiment was that this should not be discussed, at least for
> ML-KEM. I think we should remove
> this whole section.
>
> -Ekr
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
