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

Thanks!  I've merged it in.

On Fri, Sep 25, 2020 at 4:48 AM Nimrod Aviram <nimrod.aviram@gmail.com> wrote:
>
> Thanks!
> The PR is here, happy to hear comments and corrections:
> https://github.com/dstebila/draft-ietf-tls-hybrid-design/pull/1
>
> best,
> Nimrod
>
>
> On Fri, 18 Sep 2020 at 12:04, Nimrod Aviram <nimrod.aviram@gmail.com> wrote:
>>
>> 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 <douglas@stebila.ca> 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 <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" 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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls