Hi Eric, The main motivation is that, in some cases, post-quantum signatures are larger in terms of communication size compared to a post-quantum KEM, under the same cryptographic assumption.
For example, the KEM Kyber (based on module LWE) at the 128-bit security level has 800-byte public keys and 768-byte ciphertexts. The matching signature scheme Dilithium (also based on module LWE) has 1312-byte public keys and 2420-byte signatures. Doing KEM-based server authentication rather than signature-based server authentication would thus save 2164 bytes per handshake. We would still need digital signatures for a PKI (i.e., the root and intermediate CAs would sign certificates using PQ digital signature schemes), but the public key of the endpoint server can be a KEM public key, not a digital signature public key. Douglas > On Jul 12, 2021, at 20:30, Eric Rescorla <[email protected]> wrote: > > Hi folks, > > I have just given draft-celi-wiggers-tls-authkem-00.txt a quick > read. I'm struggling a bit with the rationale, which I take to be > these paragraphs: > > In this proposal we use the DH-based KEMs from [I-D.irtf-cfrg-hpke]. > We believe KEMs are especially worth discussing in the context of the > TLS protocol because NIST is in the process of standardizing post- > quantum KEM algorithms to replace "classic" key exchange (based on > elliptic curve or finite-field Diffie-Hellman [NISTPQC]). > > This proposal draws inspiration from [I-D.ietf-tls-semistatic-dh], > which is in turn based on the OPTLS proposal for TLS 1.3 [KW16]. > However, these proposals require a non-interactive key exchange: they > combine the client's public key with the server's long-term key. > This imposes a requirement that the ephemeral and static keys use the > same algorithm, which this proposal does not require. Additionally, > there are no post-quantum proposals for a non-interactive key > exchange currently considered for standardization, while several KEMs > are on the way. > > I see why this motivates using a KEM for key establishment, but I'm > not sure it motivates this design, which seems like a fairly radical > change to TLS. As I understand the situation, in the post-quantum > world we're going to have: > > - non-interactive KEMs (as you indicate above) > - some sort of signature system (otherwise we won't have certificates). > > This certainly argues that we need a KEM for key establishment, but > not for authentication. Instead, why can't we use signatures for > authentication, as TLS does today? I.e., the certificates would have a > (potentially post-quantum) signing key in them and you then use the > KEM for key establishment and the signing key for authentication. > That would give us a design much closer to the present TLS 1.3 > (effectively just defining a new group for the KEM). > > What am I missing? > > -Ekr > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
