Re: [TLS] Hybrid key exchange in TLS 1.3 and variable-length secrets

David Benjamin <> Wed, 16 September 2020 16:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12AC13A1030 for <>; Wed, 16 Sep 2020 09:48:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.944
X-Spam-Status: No, score=-10.944 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id spTyBfaKTZZu for <>; Wed, 16 Sep 2020 09:47:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5D5E73A101C for <>; Wed, 16 Sep 2020 09:47:59 -0700 (PDT)
Received: by with SMTP id z19so4304950pfn.8 for <>; Wed, 16 Sep 2020 09:47:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p3PmIEPgqlz7mQ0IkDSh8bikZGxEcfPgEN9PkSszRI4=; b=GeSSDYfflZrEmFiT7Uv67ZUQ9fHdP4ygSfHfBpDzfvfRc9tH8RCSh5qvvR/OheRQSB HoaoTUdft/0wAneg7m5c1Vzm+Yi7GTPj7u5ix1En7nEsWp6SD/uFrUdt2EQ58xDz9Gi3 S0cOsT0I4CuLgjRGynsQADzkbun9aBH+NsaWM=
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=p3PmIEPgqlz7mQ0IkDSh8bikZGxEcfPgEN9PkSszRI4=; b=chNAYFjILmyyei28BPEzUFQkYWxOT+CFUsIq7Y0tYBhaQXBHUvKEUEDOSymeIgh/q3 tl7/nmLGNtmx+u0bPbo72dsRViwPgjiohEjuYfxDHecbUkBTWkSBffIIbedIQ1DGNelT KSr8im1OwEBFcl7PYFoSaYbYGqXMTU1GSrdDiS5JZQntVspsW3Z/k81kGZIi30x0iCMS X+KVR/IyC6sROeliXr3lTWQXUmZJAgocEnfK45dKggS9Ta2unkErSzgsxRA+9klnCgiK UlEc45XyXks0YEFVoJks2Mhrp049YymnpsvPdKIcl1D25TgUwSqTXbJ0/anEpWYVwJq7 rcoQ==
X-Gm-Message-State: AOAM532vmDBlUq4tg3AxVCBQ6d/WqsOZb13XS47Iwv/EpJ/8eBtJlN4E 0oueNoL/UcunFkO21r/8LO/xqh0fzHsL2EjsFVVBD3+5AhcF
X-Google-Smtp-Source: ABdhPJzdFGQJd567TZSVnqkXQM0G6ab/pc45fqqcphzZOT2U6bny7ixMRGg3cn3cIL+BVph/wvg9q7Deuol7K5o0XhI=
X-Received: by 2002:a65:5cc2:: with SMTP id b2mr19195936pgt.124.1600274878641; Wed, 16 Sep 2020 09:47:58 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: David Benjamin <>
Date: Wed, 16 Sep 2020 12:47:42 -0400
Message-ID: <>
To: Nimrod Aviram <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="000000000000af969705af71079a"
Archived-At: <>
Subject: Re: [TLS] Hybrid key exchange in TLS 1.3 and variable-length secrets
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: Wed, 16 Sep 2020 16:48:01 -0000

"Variable-length" and "secret" don't really go together in the same
sentence, as your work demonstrates. I would actually go further and strike
that text altogether. I don't think it needs to be an open question. That
lets us stick with a simple construction.

While the public values aren't secret so there's less strong of a
guarantee, I'd go even further to drop the length prefixes inside
the HybridKeyExchange structure. That saves four bytes on the wire. If
someone does want to allocate a codepoint that needs the length prefixes,
they can always define it for that code point. (That's another nice thing
about using separate code points for separate hybrids rather than generic
crypto combinators. We don't have to design for every improbable

I will note, we did have variable-width public values in DHE, but that
caused interop issues and we fixed it in


On Wed, Sep 16, 2020 at 12:27 PM Nimrod Aviram <>

> Dear all,
> We are writing to ask about the possible security impact of
> variable-length secrets on the "Hybrid key exchange in TLS 1.3" RFC
> [1].
> As you probably know, when using key material of variable length
> and processing this material using hash functions, a timing side
> channel may arise. In broad terms, when the secret is longer, the hash
> function may need to process more blocks internally. In some unfortunate
> circumstances, this has led to timing attacks, e.g. Lucky Thirteen [2]
> and the newly-disclosed Raccoon Attack [3]. To be clear, we are not
> aware of any attack on the proposed standard. Rather, we view this as
> an opportunity to defend-in-depth against such attacks, while work on
> the standard is in progress.
> Our proposal is to add language to the RFC explaining that variable-length
> secrets may enable such attacks, and should therefore be avoided when
> possible.  Currently, the language seems to allow for variable-length
> secrets, should the need arise:
> "Variable-length shared secrets ... if it is envisioned that this
> specification
> be used with algorithms which do not have fixed-length shared secrets ..."
> We also note that a related RFC exists, "Hybrid Post-Quantum Key
> Encapsulation Methods (PQ KEM) for Transport Layer Security 1.2"
> [4]. However, that RFC apparently only uses BIKE, Kyber or SIKE as the
> PQ KEM. To our knowledge, all three KEMs have fixed-length secrets. It
> may be prudent to add cautionary language to that document as well,
> in case other KEMs are used in the future.
> Kind regards,
> The Raccoon Team
> [1]
> [2]
> [3]
> [4]
> _______________________________________________
> TLS mailing list