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

[Eric Rescorla <[e-mail]>]

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