Re: [TLS] Comments on draft-celi-wiggers-tls-authkem-00.txt

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 <ekr@rtfm.com> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls