On Fri, Apr 18, 2025 at 5:29 PM Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> wrote: > > > There’s maintenance of the code for both parts of the KEM and ensuring > > they’re properly integrated, maintenance of parallel PKI structures, need > > to allocate the costs for two moves [1] instead of one which already > > makes > > some users argue (which can be a royal pain in a large deployment), > > likely > > many other things I’m too lazy to concentrate on now (besides, there’s > > that feeling that I don’t need to convince “my” clientele at all, and > > there’s little chance to convince this audience anyway, which dampens the > > eagerness to strive). > > Thanks for writing up this list. > > > > Sure. > > > Just to check my understanding: the PKI only comes into play for signatures, > and there is no PKI needed for ephemeral key exchange as is used in TLS 1.3? > > > > An interesting point here. For the current approach – indeed, ephemeral KEX > does not need PKI. > > However, consider AuthKEM proposal, and KEMTLS – while ephemeral keys > certainly won’t depend on PKI, the static ones will.
But you can't have the AuthKEM keys going all the way up the PKI, but need a signing key. And at that point you might pick the right signature for the job at each level: big public key ok for root keys if it makes signatures smol. Intermediates have to be fairly balanced, but if you can elide, tradeoff similar. And signatures on ends need pretty quick verification. > > > > And, frankly, my work is standardizing a similar-to-above approach for other > protocols (which is not that novel – e.g., think MQV/HMQV). > > > > That’s the approach we’re following. Though we plan to submit only to other > WGs, and not TLS – because, in our opinion, KEMTLS addresses the PQ needs > quite fine, and ours would just duplicate that proposal. > > > (For the specific case of ephemeral key exchange in TLS 1.3, it seems that the > "move" is just a software update, albeit one that needs heavy testing and in > your enviroment qualification.) > > > > Essentially, yes – except that “just” in reality (for us, at least) is a lot > more involved than that. > > > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
