Re: [TLS] Finished stuffing

Hugo Krawczyk <hugo@ee.technion.ac.il> Fri, 09 September 2016 23:33 UTC

Return-Path: <hugokraw@gmail.com>
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 <tls@ietfa.amsl.com>; 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 <tls@ietfa.amsl.com>; 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 <tls@ietf.org>; Fri, 9 Sep 2016 16:33:52 -0700 (PDT)
Received: by mail-yb0-x22a.google.com with SMTP id u125so33735689ybg.3 for <tls@ietf.org>; 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: <CAOgPGoD8YEr=+c8eG+YZ=6nSvFB2uk7MiKNgN7Z=wg7ihAUhzg@mail.gmail.com> <e7729a05efe1d204bc6ee2ab2f59ae9d@maxg.info> <CABcZeBM2wqgxdsLonLzTtPChyZ14KSMwzy1HQukTL_5gXXWLmw@mail.gmail.com> <CAF8qwaB=JJ_5V9RuJNdqSmj1c=yNMANzKBksM-6TLtfnf6j57g@mail.gmail.com> <CABcZeBMhthzSWbJa_Gkt6MB-RfrAOq=VT6GU9i7GTefq0Gj2Fw@mail.gmail.com> <CADi0yUNs1+j73seG653epbSk52OnTAxnw6sLCK8kJkZqS902nw@mail.gmail.com> <CABcZeBP1hNEbxbxwxQN===CT7XdBXwQ87MG5ibsOJDS7i4gBqw@mail.gmail.com> <CADi0yUPGFF5Hgq3Ws-iMGKSBcU=gRFWz9ECd9gmjX6uvYH0OhA@mail.gmail.com> <20160908092901.d4we5xgvmktx7pmd@LK-Perkele-V2.elisa-laajakaista.fi> <CADi0yUMgnYFaQzTrHHBR39NTFWDns_Tar6z0LTF9jagUBGrJ3Q@mail.gmail.com> <20160909082237.pvl4dh2g62zrqcsg@LK-Perkele-V2.elisa-laajakaista.fi>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Fri, 9 Sep 2016 19:33:21 -0400
X-Google-Sender-Auth: clsMrqdZD8GiIDmZioHDE8n_KFU
Message-ID: <CADi0yUOqGJDQKeNN=-tn+a-JNF52DPAbYqQ+5DK5-hGRyj7oNA@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary=94eb2c191dfa343d06053c1b94b8
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lJaadxlna8EzRPTCM1oWh1AkywI>
Cc: "tls@ietf.org" <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." <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: Fri, 09 Sep 2016 23:33:55 -0000

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 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  ​larger 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 conditions
> > 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 generation
> 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 past
> > transcripts. Luckily, HKDF with the right hash functions can provide that
> > 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 that
> > too) but as a warning for future (if not present) misuse and an obstacle
> in
> > replacing HKDF in the future.
> > I would be much happier if we had a clear distinction between PRF/MAC
> > ​computations, 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.
>

​I 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 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].
> > >
> >
> > ​I 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
>