Hi all, Moving one small implementation point out of the FATT thread, since it seems orthogonal to the main discussion there.
I think a useful near-term artifact would be a short, non-blocking set of negative cases for hybrid key exchange implementations. The goal would not be to add a new proof obligation or delay any draft. It would just give implementers a few concrete cases that exercise the “both components are bound to the negotiated hybrid group and transcript” property. A first cut might include: - the negotiated group is hybrid, but one component is missing, malformed, or associated with a different group; - ECDHE and KEM values are individually valid, but assembled from different handshakes or transcript contexts; - a peer attempts to continue as standalone ECDHE or standalone ML-KEM after a hybrid group was negotiated; - traffic secrets are derived before both components have been validated and accepted under the negotiated hybrid group; - logs, exports, or API surfaces make a hybrid exchange appear as if only one component was used. If this seems useful, I can collect feedback for about a week and then turn the cleaned-up version into a GitHub issue or a small PR against the implementation-guidance text. Best, Songbo Bu
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
