Re: [TLS] Finished stuffing

Ilari Liusvaara <ilariliusvaara@welho.com> Thu, 08 September 2016 09:29 UTC

Return-Path: <ilariliusvaara@welho.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 3CE8012B3EB for <tls@ietfa.amsl.com>; Thu, 8 Sep 2016 02:29:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.408
X-Spam-Level:
X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=no
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 WIqc0VnMXyUN for <tls@ietfa.amsl.com>; Thu, 8 Sep 2016 02:29:09 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 978F212B259 for <tls@ietf.org>; Thu, 8 Sep 2016 02:29:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 3143D14995; Thu, 8 Sep 2016 12:29:07 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id tg0oLl68HZQQ; Thu, 8 Sep 2016 12:29:03 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 513BB2315; Thu, 8 Sep 2016 12:29:03 +0300 (EEST)
Date: Thu, 8 Sep 2016 12:29:01 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CADi0yUPGFF5Hgq3Ws-iMGKSBcU=gRFWz9ECd9gmjX6uvYH0OhA@mail.gmail.com>
User-Agent: NeoMutt/ (1.7.0)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/T5ZwLFo_5fUW5cgKP50SANhD__o>
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: Thu, 08 Sep 2016 09:29:11 -0000

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

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


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



-Ilari