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

Eric Rescorla <> Tue, 13 July 2021 01:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AE893A0CFC for <>; Mon, 12 Jul 2021 18:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CVXHnVV8phsH for <>; Mon, 12 Jul 2021 18:10:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 554993A0CFB for <>; Mon, 12 Jul 2021 18:10:41 -0700 (PDT)
Received: by with SMTP id u7so25014896ion.3 for <>; Mon, 12 Jul 2021 18:10:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4sba3rXk6st2kHYojldw8kYeIT/jAl7omu3ozzjsK3g=; b=Tmv5G4x1/0fnBK/EE2kfiqoOvKu+RnDlSWGQa1sSQwSiweCj+4i2DEYmwUUphfCVR+ +6po4yxgPqqzSrQzlVXODvLj5AudmLkcueKC/Utp6zpq86FKvrZmeFqylj+5HXMv1Tiw 65vJfjumffce9PwH16huKoJYCCGo5j4eH5id0Zwm0gsyOw9M4Q61UcU8oBdDfZIQ6vOI 1dQt95HZvPCFbrz4K8hOVDzsaQcA5YKQVDBIhCzjj4RTl4xUqwir2IbZTaC4W2pjXZcx nSiwfCqxVw6IuheJzEGKpW4VvZh0WhF6r9Yi2TeaultIa3Aes4rC3e7jW2I37noR6+qL NLgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4sba3rXk6st2kHYojldw8kYeIT/jAl7omu3ozzjsK3g=; b=jEreU6nB7EExk04MN/5z2Lmevm7D6M740QiOA/B9iHvVpdSE+bOBrGbWnqe7h1+29+ Q13UCc+I4+f3d8zHwsKF1yUl8nQfug8eh4iBM3MQBIEGb00Xsd8876x7PvfN+OuaUXcD Fl9LJZQ8dXnQxer+PUFQoaacjAu73VhPJYWkFipaNEfexT7XwNC3vBtKKQ4Rr1MgtXO9 YGiTMGSexSe0SvtVVYvfSkEB1zkNE0F7Z/46Gsd8Xd2LfXGIIDUhwYIIUQSGL0EZIlth Fgk0yevp4mcqRqegDsRMZWYQVA4vf7yMRn5l/qwVxuHZAW7tKAPBicRezGIjc2otTCpJ hZYA==
X-Gm-Message-State: AOAM532OGWv6ijjNdGqW308CQZqx5cyq9/5Rxo/R2BMs1tTVIfp3eA8p 3niPFh321/mV3xFxL5M8BKXwzIiuJnazgTqXXd7xKw==
X-Google-Smtp-Source: ABdhPJxo6YHKHcCd5eED9vEIITCmbgSKM4jb85no0WdxYih8ibaoWMOF+K8iOFcKDUtqSN40Wbj8whA2rly00ysHGo4=
X-Received: by 2002:a02:8184:: with SMTP id n4mr1536089jag.17.1626138640271; Mon, 12 Jul 2021 18:10:40 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Mon, 12 Jul 2021 18:10:04 -0700
Message-ID: <>
To: Douglas Stebila <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="000000000000025cca05c6f6e86a"
Archived-At: <>
Subject: Re: [TLS] Comments on draft-celi-wiggers-tls-authkem-00.txt
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Jul 2021 01:10:44 -0000

On Mon, Jul 12, 2021 at 5:58 PM Douglas Stebila <> wrote:

> 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.


Thanks for the explanation.

I agree that all things being equal it's good to save bytes, but in this
case, I think this is the wrong tradeoff.

In general, TLS handshake latency is dominated not by message size but by
the number of round trips you have to use to perform the handshake, which
is only loosely coupled to the number of bytes.

- If you are doing TLS over TCP, then the server can use IW10 as specified
in RFC 6928. This will allow the server's first flight to be about 14 KB,
which should be large enough.
- If you are doing QUIC, then the server is restricted to 3x the client's
initial message, which is potentially a problem with very large server
first flights, but the client can add extra bytes to its Initial messages
to increase the limit [0]

And of course, there are mechanisms for shrinking the handshake, such as
RFC 8879 certificate compression or draft=thomson-tls-sic.

So, while I'm not that enthusiastic about paying a few K, I think on
balance it's a better than doing this kind of major rearchitecture of TLS.


[0] Or the server can send a Retry packet, incurring a round trip, but this
only needs to be done the first time as long as the client's IP doesn't

> > On Jul 12, 2021, at 20:30, Eric Rescorla <> 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
> >
> >