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

Nimrod Aviram <nimrod.aviram@gmail.com> Wed, 16 September 2020 16:27 UTC

Return-Path: <nimrod.aviram@gmail.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 1753B3A0E0D for <tls@ietfa.amsl.com>; Wed, 16 Sep 2020 09:27:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DyRKu8kh3XPS for <tls@ietfa.amsl.com>; Wed, 16 Sep 2020 09:27:09 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 52FBB3A0DF0 for <tls@ietf.org>; Wed, 16 Sep 2020 09:27:09 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id w186so8827499qkd.1 for <tls@ietf.org>; Wed, 16 Sep 2020 09:27:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ZSGGxmuZTTnVfbAxKNF96mhA03N8Cy/7+ytEv5cxFag=; b=BLTJO0NLsEKyx0MBp63Nv5Sg4L/hw0RANvifOybRp/kSm02mbDwGfUfrlAJws01jV/ 2TuT7MPqBtPtIPcgj17Jqn7Jyv4b49IoXylUjJxpCD49sepQrqGN9lb6o/pmRRC9qdfP bMrJ8eTgyoEnyXc+6u8ZirzeLHNlDDPlBdcFBakasq3ctTSzkMT+3fCAHkIGwiZ7x7Wv ACmpO228qd2A9m+XODtX11Awh/chPvQX7fxlycPvkeEu8uKN+p0ldJBkPruCmqSdOLCj k0aal2edUW7wNEMNRbjRHt1Zjbrbe3Nx75fz9QmrguMtn4DUDYi355HVH+uJlWFgO5uD dKdw==
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=ZSGGxmuZTTnVfbAxKNF96mhA03N8Cy/7+ytEv5cxFag=; b=gCc8yDIrfn+ZSD4u3zAk5efeP8+hSV9AYvP5XAKHAXmxwD6EZX7HLc3scNbxCzETSF ugF7HFdBKtAE8s4zytH4TAtfp98qHhrbHVi+MeUy9beTz3QbXjP21mwlEx+akCDDT7lC U9axZUfc8TC1vM/6hI2Qk31VbrsNGqZ74w/5OH30sRx9fJphSUPK4B6FFKUEFmPXnX2C LNFYxzJqjXqtpeMs7k9QYTGpR1JeDxnNYeIsmb1N39uYsckwtp5Y34euXpPbJwku9XfJ uk7t4J/jCckEyLSqP64Hk4/pFtPa6Z+G3ML5Qh6SnijlPYqszVqY+giXOqOLlpkLk9c6 nQGg==
X-Gm-Message-State: AOAM532cTN1T2ZcITEvuyOXKEifeqPmxOoVVmsKXXtaYSg5yYv9muJGy +DGsTXO0H5aELtm0CKyt9Lf6TKzNMaxjqxCIT4Zs7QdplsHHgA==
X-Google-Smtp-Source: ABdhPJz4F04rOh1xsY4ROrJDNTNRCf07ZS+8lnbdjYofajfjAuKiWvhev00TKRIhC8CLlx0QTJnOmMdGbf2hvcFi1dc=
X-Received: by 2002:a37:e118:: with SMTP id c24mr25070206qkm.167.1600273627944; Wed, 16 Sep 2020 09:27:07 -0700 (PDT)
MIME-Version: 1.0
From: Nimrod Aviram <nimrod.aviram@gmail.com>
Date: Wed, 16 Sep 2020 19:26:56 +0300
Message-ID: <CABiKAoSGpodvQAegOhDxKxvDWoUsZBZL2JFWbtyseH+19cj6VQ@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000023190e05af70bda3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/6ORHUjSUjQVMBX8Swhdcf5iPok8>
Subject: [TLS] Hybrid key exchange in TLS 1.3 and variable-length secrets
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: Wed, 16 Sep 2020 16:27:11 -0000

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

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

[2] https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6547131
[3] https://raccoon-attack.com/