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> 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
