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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 099D33A0EF0 for <>; Wed, 16 Sep 2020 09:57:19 -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 vRtsyEBVrdrZ for <>; Wed, 16 Sep 2020 09:57:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9788C3A0CA1 for <>; Wed, 16 Sep 2020 09:57:16 -0700 (PDT)
Received: by with SMTP id b17so1844068pji.1 for <>; Wed, 16 Sep 2020 09:57:16 -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=8a3Jrx3UdX/SVJVKIx1FyX1SCC6K/lBLScrfUyJF6pE=; b=S3X89YRH/jSm8/kynHHiYzYSEIZLlZ6TL0gj9kqbgiu4wCTaV1tAaT0gXL7r/R4Qle QcLHFH2XV+OWEwWI4NyUXaNjfd4/g/KcuKq2uVaOYuVYkg/x8q1P7KQojxIzwIxMCPi2 vGX/K55hNTLxtFSXtywq+gnEfJTbkBhsmfb0U=
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=8a3Jrx3UdX/SVJVKIx1FyX1SCC6K/lBLScrfUyJF6pE=; b=CEubzDXU2y6q5DITrQASUOYoSQ9GsjJpgO5b9tsZH0I5L3GPliYuwYVXsDEHEYuehD HrAq7aTJ1fuR4gRJ4Rg0cU8TGCZeHZpqwzP3ycOFs5blAEXsx6pfMd3hfsAu5j0L3SQ3 Kwe3+80v2gn6I5vlkSSMbkN13FBILkCOh31ep0Cdu2k+56xZ2LzyVwD5xeRA7zbTT5we FXVizG5Hz98RKJPVlVNxzY0QJym7ClEDtbsQ2dJkAceIYTN1RJ/8tllRuXIZzg51Dv/M diETfRM8jegnjVPwktMZpH1ai36FX1i4f4oLScRmVicYf8j9nuG0ZGqPlWNP+jdK8kcd odiw==
X-Gm-Message-State: AOAM530dWiJrnXua7F1Fju0v7K4K30F2wBj9gMjMbNUJxc3rvWVqsui0 +0L6AA+xjfH49IeKYac6iCC/49cDppIhlCsmDazd
X-Google-Smtp-Source: ABdhPJzDEjPHmTLlqd+5zg568kP6BlOT+3kum2AgkRpnYuhKIMkqCr1sXZQHSta6WziPMelEO5+PmChhgo+uKtAXOgg=
X-Received: by 2002:a17:902:c411:b029:d0:589f:6e1c with SMTP id k17-20020a170902c411b02900d0589f6e1cmr25454310plk.0.1600275435785; Wed, 16 Sep 2020 09:57:15 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Wed, 16 Sep 2020 12:56:59 -0400
Message-ID: <>
To: Nimrod Aviram <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="000000000000e50bba05af712850"
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:57:19 -0000

On Wed, Sep 16, 2020 at 12:47 PM David Benjamin <>

> "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
> possibility.)

I see the draft mentions SIKE having both compressed and uncompressed
variants as a justification, but that's not a reason for variable-length
public values. Any TLS code point using such a KEM should pick a particular
encoding so there's just the one mode, in the same way that ECDH keys have
both compressed and uncompressed encodings, but RFC8446 picks a single
format. ( Allowing both
means we either need a negotiation (so they should have been separate code
points), or we end up with a giant interop and complexity mess.

> I will note, we did have variable-width public values in DHE, but that
> caused interop issues and we fixed it in
> David
> On Wed, Sep 16, 2020 at 12:27 PM Nimrod Aviram <>
> wrote:
>> 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