Re: [TLS] Finished stuffing

Hugo Krawczyk <hugo@ee.technion.ac.il> Fri, 09 September 2016 02:05 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 1F55C12B053 for <tls@ietfa.amsl.com>; Thu, 8 Sep 2016 19:05:39 -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=unavailable 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 C1_ssBBePh_9 for <tls@ietfa.amsl.com>; Thu, 8 Sep 2016 19:05:37 -0700 (PDT)
Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (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 1CE2F12B338 for <tls@ietf.org>; Thu, 8 Sep 2016 18:59:54 -0700 (PDT)
Received: by mail-yb0-x234.google.com with SMTP id g5so23515231yba.2 for <tls@ietf.org>; Thu, 08 Sep 2016 18:59:54 -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=quI/UykzyPfDiHEqreZQpMMDSnf8pCkp6LRAm7YIy6k=; b=bPUPui6d6L5iwCBojhH5VzIykv9wNR+WuQpvyoHmEPTsNJt2npJGifB15Mrxn+gAcA jNWk9A/FRDwcL9kx/cJ8Y70J1dEE1LFNMZlCLJTVS8u6gHJxKtkOoxtP968O/wVjq/Qn 1NMGkPc+qNcTmmvhjYsSHkGpoqqXuSLv/lhIfHxkpQom3KXU0AclrKMNMa3h2liY+Xcr HJFhXcwZDOCljPXhh/OGHa3Ty3GWdUils4ptW85WP5SHnHn+64PEHLqc7qkpHR9pQ8tq f6c0MUk2ZOjsF3SphlTxw9bqkharRe8mVF2qZEktM7NXib9R2la3yXe9bpNn1g5PnBXM KJHw==
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=quI/UykzyPfDiHEqreZQpMMDSnf8pCkp6LRAm7YIy6k=; b=ZxUmGvjFJC3dWjNKHmQ+okPahHDxSdeUAuWo5VGGOPErOG5zBjKd5CWNtRkBkv3qAq liFooeCjykfH+JD3pfUNpE/U7MCApKOG1icSAfu21n7olvcA/KXjhufj4d+mL8nJmI+Y 16aSFlAdvnX9YzU/MZ/4ojbJKYQthg5vaMqwQZuxg3n5pBgFCf8UTXt9j4qHJK3GrPjZ iUDo2UFwOZn8Vd6k1LxEvFIUkeDVID02KuXpt75fxkgUkQKMb6wJz4Nu26Czw2MZOBat irEXynqmct9e6uTn7MHj+toXDGF4rfeWi5nvm2qe29xw3w8SKhailwW8eJ6aS2Gbh2AV 3dqg==
X-Gm-Message-State: AE9vXwMTHTKTpcRpqy0ZfXu5efWp8oxCxIWcz6jvuYBkGjErqWDE/bZFAIruHhzPs4xmIwUlMubxie8PeSqgLg==
X-Received: by 10.37.206.84 with SMTP id x81mr973371ybe.117.1473386393255; Thu, 08 Sep 2016 18:59:53 -0700 (PDT)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.37.33.10 with HTTP; Thu, 8 Sep 2016 18:59:22 -0700 (PDT)
In-Reply-To: <20160908092901.d4we5xgvmktx7pmd@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBP890QrcbpGR9Ht2RkfHShavkkDmvvKPP+81x8Bz+SeDA@mail.gmail.com> <CAF8qwaCVyRrSm-XtL6Jd_VKD9qGmCJNFJW1GZVjmidsr3DnW_Q@mail.gmail.com> <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>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Thu, 8 Sep 2016 21:59:22 -0400
X-Google-Sender-Auth: QqL7f_-FtI69rtDRfAKrheuLBAg
Message-ID: <CADi0yUMgnYFaQzTrHHBR39NTFWDns_Tar6z0LTF9jagUBGrJ3Q@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary=94eb2c191dfa96465b053c0980c5
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GkCcoXEfRwMOGErZ8UIeFbIk8QM>
Cc: Antoine Delignat-Lavaud <antoine@delignat-lavaud.fr>, "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 02:05:39 -0000

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:
> > On Wed, Sep 7, 2016 at 7:18 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> > >
> > >
> > > On Wed, Sep 7, 2016 at 4:02 PM, Hugo Krawczyk <hugo@ee.technion.ac.il>
> > > wrote:
> > >
> > > I also have a problem with names. "Resumption context" is very explicit
> > >> about providing, well, resumption context.
> > >> "Hello_Finished", in turn, means nothing.
> > >> Also, RC may better match the notion of "binder" hence more naturally
> > >> requiring collision resistance, while all Finished uses in TLS (1.3
> and
> > >> before) have a MAC functionality (for which, say, 128 bits are good
> enough)
> > >> and it would be better not to abuse them for other uses.
> > >>
> > >
> > > Two points about this:
> > >
> > > 1. The Finished in TLS 1.3 is always Hash.length, and our minimum hash
> is
> > > SHA-256, so I believe we have enough strength here. We could of course
> > > require a minimum size.
> > >
> >
> > ​If you keep this, you definitely need to have a minimum size
> specification
> > in boldface.
>
> Well, the PRF hash is already assumed to be CR, and if HKDF is used with
> certain restrictions, it preserves CR:
>
> - 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.


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

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.


> Furthermore Finished construction uses HMAC. There for CR-preserving,
> one needs key to be of constant length (it always is hash_olen).
>
>
> Then there's things that are "nonces":
>
> - Exporter master secret
> - Resumption master secret
> - hello_finished
> - Some outputs of TLS exporter (depending on application).
>
> So I would be more concerned about some future extension changing the
> way things are computed, breaking CR-preserving, or someone adding a
> weak PRF hash. ​
>
>
​Agreed.
​
​


>
> (Of course, if SHA-2 breaks, we have really messy practical problem
> too...)
>
>
> > > 2. I wouldn't object to changing names here, of course.
> > >
> >
> > ​I think that's a must. "Finished" says absolutely nothing about the
> > functionality of this extension (it may actually mislead to think of it
> as
> > a MAC of some sorts).
> > Call it something that can be understood as  "PSK Creation Binder" and
> make
> > sure to specify (and explain in English) that all the values in the key
> > derivation chain to lead to this value are collision resistant mappings
> of
> > the original handshake context (including the server's certificate).
>
> 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].
>
>
> [1] Apparently combined authentication is to be in separate spec[2], but
> the main spec needs to be safe with it.
>
> [2] There apparently the server signature_algorithms to "support" that,
> except I can't figure out _any_ use for that except a footgun[3].
>
> [3] If using PSK, it has ill-defined semantics. If not, it pretty much
> only useful for attacking the client.
>

​I could not follow this argument.

Hugo
​


>
> ​
>
>
> -Ilari
>