Hi Bas, I prefer for the MTI to be P-256+Kyber768 for compliance reasons.
It would be trivial for servers to add support for both identifiers as they introduce Kyber768, but you are right, the new draft should include an MTI identifier. From: TLS <tls-boun...@ietf.org> On Behalf Of Bas Westerbaan Sent: Friday, March 31, 2023 8:04 PM To: Ilari Liusvaara <ilariliusva...@welho.com> Cc: TLS@ietf.org Subject: RE: [EXTERNAL][TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Regarding additional key agreements. For the (public) web it would be best if we can agree on a default key agreement. If one half uses P-256+Kyber768 and the other X25519+Kyber768, then clients will either HRR half the time or need to send both. Neither are ideal. Obviously this point is moot for internal networks. So I do not oppose specifying additional preliminary key agreements, but I do not like to actively support it. What about specifying further preliminary key agreements in yet again a separate draft? Best, Bas On Sat, Apr 1, 2023 at 1:56 AM Bas Westerbaan <b...@cloudflare.com<mailto:b...@cloudflare.com>> wrote: The draft draft-tls-westerbaan-xyber768d00-00 references draft-cfrg-schwabe-kyber-01, which has a number of annoying mistakes, since fixed in editor's copy. And then, the correct reference for X25519 is probably RFC7748 instead of RFC8037... Really quick and dirty way to fix this would be to publish editor's copy as draft-cfrg-schwabe-kyber-02 (or if CFRG adapts quickly, the RG-00), and then publish draft-tls-westerbaan-xyber768d00-01, fixing the references. Thanks, done. Posted -02 of both the Kyber and Xyber drafts. Best, Bas
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
