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

Eric Rescorla <ekr@rtfm.com> Tue, 13 July 2021 00:31 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D50CC3A1148 for <tls@ietfa.amsl.com>; Mon, 12 Jul 2021 17:31:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5J9EXxG4WCOi for <tls@ietfa.amsl.com>; Mon, 12 Jul 2021 17:31:04 -0700 (PDT)
Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C99883A1147 for <tls@ietf.org>; Mon, 12 Jul 2021 17:31:04 -0700 (PDT)
Received: by mail-il1-x129.google.com with SMTP id z1so21475607ils.0 for <tls@ietf.org>; Mon, 12 Jul 2021 17:31:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=D5ZNdfV82PQVE8oEl09FIVY5905kQ1Wyh7EB6zHdegU=; b=u5zGZsUF0I670NaKYZ7wyrNn1SKz9OKemvMADMhdHN/WXAApZQ7gFDWlp6kxAUVWYw mDWxawgsQeni4AGq/ysobaX8yB22TCPlVjElYgVUt1lT9c+4n9vLQ1u1ZjmIoEDad5Dm axq8wiyXKSfPYp0Yd6OR/VpZ3VfrLW+oQOg+zZu/Fqk87erKjidiXPPZUIj66pFN1AWS 8bc3Kk23uhZe7ICh39wo+XGavm7VXbSs1gP8qRHcVEm8JB7lgt/LxNhcgfIQSfi+R7zi VKBHwVJHgbr3AWzWUlWoj97CoF1Ahjj1vRNczjbSr5xetEvMRo02hcTmKDrZW3ODvq5y xh2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=D5ZNdfV82PQVE8oEl09FIVY5905kQ1Wyh7EB6zHdegU=; b=FucuAW7EIMQYkAMZWderbmKifvfScFZobNFiv5VREBGJ2IJnYasptk1uATSqvAgJEA ISrZ0xQzuRa3A3IDh9YUCIGxvAfDIFwLXbx5LMdMWiJ07wUkg7aFS3/+Z0z3q6twWIgW kATGNTU7PP3PPiwTfJ8YgcTQYpacj0mcGOP3LlhsIzNxqH0IDfsn009TsbA2wtPAMZN/ jgDcpcAZGnZq9gXf1wzk7aG/v4bSh17MApgx+Yz1VU+m5PAdKRmZ/vSmMzR6SqXiBOEU 1+QVMdcgxb3d3T2YZkVVLwbz0rO7YDQ3vnNHEfvRNCtL+nzoc0k4e8zkd8ntobQzXz/7 ZiPw==
X-Gm-Message-State: AOAM532hIZ8FyM0T5qRiMoLIOcpBq6GKXUFZX7Tg/Ikb7KcgbtzAtyiP six1hjK/bmlF4Z/W/Z3+4FSSW+Sy7+E/68HBwSNd4LJRgnJadJ/4
X-Google-Smtp-Source: ABdhPJwPGPXZSgZrdx47ASnrId41YC+C/HmiUMOwXgi86BzH37mHS2N0TXZ468Tselv8dO+BZTYtWOXGMxmBKDurJHU=
X-Received: by 2002:a92:8e03:: with SMTP id c3mr1021476ild.167.1626136262937; Mon, 12 Jul 2021 17:31:02 -0700 (PDT)
MIME-Version: 1.0
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 12 Jul 2021 17:30:26 -0700
Message-ID: <CABcZeBN4y40o7T3hx4RH3LogbMDEScxGY4SVuCWuQ67oW+XZ3w@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004f2d3e05c6f65a9e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/d0t5oHTDnYlQW0_SZXyJ5NFCnsE>
Subject: [TLS] Comments on draft-celi-wiggers-tls-authkem-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Jul 2021 00:31:08 -0000

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?