From nobody Fri Sep 18 02:04:21 2020 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7633A1078 for ; Fri, 18 Sep 2020 02:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpkYGum5GgxO for ; Fri, 18 Sep 2020 02:04:17 -0700 (PDT) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 7E2EE3A1077 for ; Fri, 18 Sep 2020 02:04:17 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id f11so2500623qvw.3 for ; Fri, 18 Sep 2020 02:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kSM/5ua1HN4Rfd9KepohPSbsnJl2EfU/Eb6sZJDi5nA=; b=EuOgZg5q11AujnAnwnCrDxqGxh4fcddVBUrMKMjmubtx9DFqz642nBXF8tffh0Lkhz +HprFe5Kd3h9P4C2VHjM1mQmmsEOMOCsycbhsuD6W8CylvHPSKX1/X0sQpIizSV49VYb JPmYi38tuJttJomHApTuAWpJ7QnWJnwWTkHVlj3580I87l+QCSSCp68VmGP6xq7fP15l lS9XgwT37PQqomu+XuTVbMmxNqkmXKYAYqgOjuxYyDcFkcQ/EpJkMSx4Z6NKf942g332 Y1slP7dNLmWwZdmAeLpn9ixmDZ1QiglSdCIS7zZmJ9xrOceekSgArcHmL25bxEoMrZum adKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kSM/5ua1HN4Rfd9KepohPSbsnJl2EfU/Eb6sZJDi5nA=; b=Y/qiP0h6sgYSgpeHuG+uvSuqtnNZVQOhdDcbuqb5ONifp84kNT/BOt6o2Jl7oFGABo ZljGmhBv3IcNCcGhfWML3gGPFT5crCyw/PR0lbqqVupAQUomrmfNwOOVqFGllzQzBPfE Cnki3jRPwCxcF0IH3JqIJKGHrG65lqvKfHcq7LctNGWcnB4luk+z2OTo+25bbSV0otpm i1CYa7uCclyAyKLKFWSj0W/H5ShZ3Rdwt5jPFZnR0oJL0fak/c6wln4EEXzZ7b+4hvV3 DWURZkMbExc0m5QGZF61k4VKoe9ZWdssHAImJhmEB0xz9dLRalVWPa7xX8Kp137QWxnX lDKA== X-Gm-Message-State: AOAM530UwRViDhpDIkOlbNbIWqq10q2LsbPyI72Gq1cnilzVA/rSmg5F e7YODJFSLs7FaYtzLlfiyXXQp0M4w0ZRcPfVLH6AgFeymIs= X-Google-Smtp-Source: ABdhPJzR+FNu9vhe8FIYCubUzX2AuTAd4lrWT4gp/2WqyDTxf3toBQuyyOqesoXh36GVcL6t6oiDM5+hD3K+/Gsow0Y= X-Received: by 2002:a0c:e543:: with SMTP id n3mr32784863qvm.11.1600419856426; Fri, 18 Sep 2020 02:04:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nimrod Aviram Date: Fri, 18 Sep 2020 12:04:05 +0300 Message-ID: To: Douglas Stebila Cc: "" Content-Type: multipart/alternative; boundary="00000000000008ac0205af92c9b1" Archived-At: Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2020 09:04:19 -0000 --00000000000008ac0205af92c9b1 Content-Type: text/plain; charset="UTF-8" Sounds good to me. I'm happy to send a PR making these changes, but couldn't find the repository for the document. Could you please point me to it? best, Nimrod On Thu, 17 Sep 2020 at 17:12, Douglas Stebila wrote: > Given that all the finalists and alternate candidates have fixed > length shared secrets, and your observations on the potential for > timing attacks, I'm fine with dealing with only fixed length secrets, > removing the paragraph discussing the possibility for variable-length > shared secrets from the TLS 1.3 hybrid KEX draft, and adding a note > regarding the risks as identified by the Raccoon attack. > > Douglas > > > 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] > https://www.ietf.org/id/draft-ietf-tls-hybrid-design-00.html#name-open-questions > > [2] https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6547131 > > [3] https://raccoon-attack.com/ > > [4] > https://tools.ietf.org/id/draft-campagna-tls-bike-sike-hybrid-05.html#name-key-exchange-algorithms > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > --00000000000008ac0205af92c9b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sou= nds good to me.
I'm happy to send a PR making these changes, but couldn't find the= repository for the document.
Could you please point me to it?

best,
Nimrod


On Thu, 17 Sep 2020 at 17:12, Douglas Stebila <douglas@stebila.ca> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Given that all the finalis= ts and alternate candidates have fixed
length shared secrets, and your observations on the potential for
timing attacks, I'm fine with dealing with only fixed length secrets, removing the paragraph discussing the possibility for variable-length
shared secrets from the TLS 1.3 hybrid KEX draft, and adding a note
regarding the risks as identified by the Raccoon attack.

Douglas


On Wed, Sep 16, 2020 at 12:27 PM Nimrod Aviram <nimrod.aviram@gmail.com> 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&qu= ot; 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 unfortuna= te
> 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<= br> > an opportunity to defend-in-depth against such attacks, while work on<= br> > the standard is in progress.
>
> Our proposal is to add language to the RFC explaining that variable-le= ngth
> secrets may enable such attacks, and should therefore be avoided when<= br> > possible.=C2=A0 Currently, the language seems to allow for variable-le= ngth
> 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<= br> > Encapsulation Methods (PQ KEM) for Transport Layer Security 1.2"<= br> > [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] https://www= .ietf.org/id/draft-ietf-tls-hybrid-design-00.html#name-open-questions > [2] https://ieeexplore.ieee.org/s= tamp/stamp.jsp?arnumber=3D6547131
> [3] https://raccoon-attack.com/
> [4] https://tools.ietf.org/id/draft-campagna-tls-bike-sike-hybrid-05.htm= l#name-key-exchange-algorithms
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
--00000000000008ac0205af92c9b1--