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 1DE1C12B15B for ; Fri, 9 Sep 2016 16:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 XSFt9q01sCyo for ; Fri, 9 Sep 2016 16:33:53 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 BDC8812B041 for ; Fri, 9 Sep 2016 16:33:52 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id u125so33735689ybg.3 for ; Fri, 09 Sep 2016 16:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=19eq6R9IZpk33zJBciXN/ucBmoJUSIeo9Q6F97rV8lk=; b=H2K3W8FrK9HL8SBrI5fxqlcJ9rsed4pPHemXsc0h2N3SzEWtbIlSxXqCTbMPfsA06f u2HMhBNiOafpt3tiiadm2cPJwDAXnQwZ4pm6Hww7oVW6h1HLnYA4nN3ArL47qimeHbt1 EjyypSIXL6GphhXd+cmU9K9PmEat1VP4yOpn7rfJqcLDa/3bAnf26QrAhDfgPORGBWtV 73ZxwigNQwKXGOnTPEqQZG3fMGOI2se8El+e1o7hwMTwz7mNerz7Cwhx+2TIxCykass1 CuEazYHHtNTkwFcre4tYSttmmLYMRJWxLsUbyjKDJt3UJhHla2lgA0GHUbuqsqpaRULa qIMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=19eq6R9IZpk33zJBciXN/ucBmoJUSIeo9Q6F97rV8lk=; b=VgwBIQe6K3aPyHOj2aFVZKsIbL97GeqToB1QKVmvddvZ51p6L3ntxeuUzLpDuOvmMJ PJFBL/OEq/Zc7itpD3GRaqyWimwOLMPENza9pzZOX3bZO2oLEmwqFbBIKAwvNzYsQhXu gU+BP/xGyS91steHfURV6zeE0Y04JEmMyKLYi8Kl/1o+J5RbJxaIph8bKViwmEqDkOSc IO2nwy+DKMOtAhXDYrJVHBsLfsa11OwyYlp4bC6JODfKGpJUyQGUHabg2+cX1dToommV HoBQ4UQ4FTunmZSKD8k81ZRDp5W9kcy25LbnQt8jsZ33Eb5x3bK7iDf8yvkbC6a4y55S SQGg== X-Gm-Message-State: AE9vXwPLdcws11Ub+64D37HcDK/YmCzfVrz2mujxzDdyjZGp7mvj/DnrzE/Lem3DoXdbCf/bEyflNK5lJkwChA== X-Received: by 10.37.206.84 with SMTP id x81mr6756973ybe.117.1473464031786; Fri, 09 Sep 2016 16:33:51 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.37.33.10 with HTTP; Fri, 9 Sep 2016 16:33:21 -0700 (PDT) In-Reply-To: <20160909082237.pvl4dh2g62zrqcsg@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160908092901.d4we5xgvmktx7pmd@LK-Perkele-V2.elisa-laajakaista.fi> <20160909082237.pvl4dh2g62zrqcsg@LK-Perkele-V2.elisa-laajakaista.fi> From: Hugo Krawczyk Date: Fri, 9 Sep 2016 19:33:21 -0400 X-Google-Sender-Auth: clsMrqdZD8GiIDmZioHDE8n_KFU Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c191dfa343d06053c1b94b8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Finished stuffing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 09 Sep 2016 23:33:55 -0000 --94eb2c191dfa343d06053c1b94b8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Sep 9, 2016 at 4:22 AM, Ilari Liusvaara wrote: > On Thu, Sep 08, 2016 at 09:59:22PM -0400, Hugo Krawczyk wrote: > > On Thu, Sep 8, 2016 at 5:29 AM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > On Wed, Sep 07, 2016 at 07:43:53PM -0400, Hugo Krawczyk wrote: > > > > > > - The hash has output length at most input length (true for all SHA-2 > > > variants) > > > > > > > Just curious: Can you explain the need for this property? Note that if = a > > key to HMAC is =E2=80=8Blarger than the (compression) function output = size then > > this key is first hashed into a full output hence preserving CR. > > Simply me not bothering to figure out what the heck HMAC does if this > isn't true (or if it is even well-defined in all cases). > > > - HKDF-extract salt length is constant (in current draft, always > hash_olen) > > > - HKDF-expand PRK length is constant (in current draft, always > hash_olen) > > > - The HKDF-expand output output length is at least hash output length > > > (in current draft, hash_olen except in key expansions). > > > > > > > These are a lot of restrictions that no one has spelled out as conditio= ns > > on the KDF and they do not follow from the natural properties of KDFs. > > Collision resistance is never needed as far as I can tell for generatio= n > of > > keys or to compute PRF and/or MAC values (e.g., for the original > > functionality of Finished that is essentially a MAC/PRF on the > transcript). > > The reason we find ourselves considering the CR properties of HKDF is > that > > we are using it to derive *strings* that serve as binders/digests of pa= st > > transcripts. Luckily, HKDF with the right hash functions can provide th= at > > functionality but it is not a native KDF functionality. > > So I presume some more text for Security Considerations... > > > I do not mean this as an academic discussion (although we could have th= at > > too) but as a warning for future (if not present) misuse and an obstacl= e > in > > replacing HKDF in the future. > > I would be much happier if we had a clear distinction between PRF/MAC > > =E2=80=8Bcomputations, KDF computations and digest computations., even = if we > > currently used HKDF for all these functions. > > Unfortunately there are things like exporter outputs, that need to be > both "secret" (i.e. "keys") and "nonces" (i.e. "binders"). At least if > application wants so... Dropping either would cause MAJOR security > problems. > > I think those and the dynamically provisioned PSKs are the only ones > that have that property of being both key and binder. > =E2=80=8BI would much prefer to have two elements associated with such keys= . One is the key itself and the other is a binder (or whatever other name one chooses for it) that consists of a context string or digest associated to that key. Then, you would use the key to key crypto algorithms and use the descriptor as a binder to the key's original context, usually as input to a crypto algorithm (and not as a key). This will make the functionality of each element (key or binder) more explicit and will make it clear when is that we need collision resistance and when we don't. Hugo > > > It is a bit more problematic than that: > > > > > > The hello_finished / "PSK Creation Binder" derives from the PSK key. > > > > > > Deriving separate value in context of dynamic PSK provisioning does n= ot > > > work properly as "static" PSKs lack this value, and if one then tries > to > > > use such key with combined authentication, you got an attack[1]. > > > > > > > =E2=80=8BI could not follow this argument. > > Basically, one can't make a distinction between static ("non-resumption) > and dynamic ("resumption") PSKs here. Because such distinction would > run into security problems with some other features. > > > > -Ilari > --94eb2c191dfa343d06053c1b94b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Sep 9, 2016 at 4:22 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Thu, Sep 08, 2016 at 09:59:22PM -0400, Hugo Krawczyk wrot= e:
> On Thu, Sep 8, 2016 at 5:29 AM, Ilari Liusvaara <ilariliusvaara@welho.com>= ;
> wrote:
>
> > On Wed, Sep 07, 2016 at 07:43:53PM -0400, Hugo Krawczyk wrote: > >
> > - The hash has output length at most input length (t= rue for all SHA-2
> > variants)
> >
>
> Just curious: Can you explain the need for this property? Note that if= a
> key to HMAC is=C2=A0 =E2=80=8Blarger than the (compression) function o= utput size then
> this key is first hashed into a full output hence preserving CR.

Simply me not bothering to figure out what the heck HMAC does if thi= s
isn't true (or if it is even well-defined in all cases).

> - HKDF-extract salt length is constant (in current draft, always hash_= olen)
> > - HKDF-expand PRK length is constant (in current draft, always ha= sh_olen)
> > - The HKDF-expand output output length is at least hash output le= ngth
> >=C2=A0 =C2=A0(in current draft, hash_olen except in key expansions= ).
> >
>
> These are a lot of restrictions that no one has spelled out as conditi= ons
> on the KDF and they do not follow from the natural properties of KDFs.=
> Collision resistance is never needed as far as I can tell for generati= on of
> keys or to compute PRF and/or MAC values (e.g., for the original
> functionality of Finished that is essentially a MAC/PRF on the transcr= ipt).
> The reason we find ourselves considering the CR properties of HKDF is = that
> we are using it to derive *strings* that serve as binders/digests of p= ast
> transcripts. Luckily, HKDF with the right hash functions can provide t= hat
> functionality but it is not a native KDF functionality.

So I presume some more text for Security Considerations...

> I do not mean this as an academic discussion (although we could have t= hat
> too) but as a warning for future (if not present) misuse and an obstac= le in
> replacing HKDF in the future.
> I would be much happier if we had a clear distinction between PRF/MAC<= br> > =E2=80=8Bcomputations, KDF computations and digest computations., even= if we
> currently used HKDF for all these functions.

Unfortunately there are things like exporter outputs, that need to b= e
both "secret" (i.e. "keys") and "nonces" (i.e= . "binders"). At least if
application wants so... Dropping either would cause MAJOR security
problems.

I think those and the dynamically provisioned PSKs are the only ones
that have that property of being both key and binder.
=
=E2=80=8BI would much prefer to ha= ve two elements associated with such keys. One is the key itself and the ot= her is a binder (or whatever other name one chooses for it) that consists o= f a context string or digest associated to that key. Then, you would use th= e key to key crypto algorithms and use the descriptor as a binder to the ke= y's original context, usually as input to a crypto algorithm (and not a= s a key). This will make the functionality of each element (key or binder) = more explicit and will make it clear when is that we need collision resista= nce and when we don't.=C2=A0
=
Hugo


> > It is a bit more problematic than that:
> >
> > The hello_finished / "PSK Creation Binder" derives from= the PSK key.
> >
> > Deriving separate value in context of dynamic PSK provisioning do= es not
> > work properly as "static" PSKs lack this value, and if = one then tries to
> > use such key with combined authentication, you got an attack[1].<= br> > >
>
> =E2=80=8BI could not follow this argument.

Basically, one can't make a distinction between static ("no= n-resumption)
and dynamic ("resumption") PSKs here. Because such distinction wo= uld
run into security problems with some other features.



-Ilari

--94eb2c191dfa343d06053c1b94b8--