Re: [TLS] confirming the room’s consensus: adopt HKDF PRF for TLS 1.3
Michael StJohns <msj@nthpermutation.com> Mon, 27 April 2015 00:59 UTC
Return-Path: <msj@nthpermutation.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE441B2CB2 for <tls@ietfa.amsl.com>; Sun, 26 Apr 2015 17:59:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 FUVoJkkWniCg for <tls@ietfa.amsl.com>; Sun, 26 Apr 2015 17:59:23 -0700 (PDT)
Received: from mail-vn0-f46.google.com (mail-vn0-f46.google.com [209.85.216.46]) (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 884721B2CAD for <tls@ietf.org>; Sun, 26 Apr 2015 17:59:23 -0700 (PDT)
Received: by vnbf1 with SMTP id f1so10174748vnb.0 for <tls@ietf.org>; Sun, 26 Apr 2015 17:59:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DhbdtjkKJd3BCAgzju0TICP/tHOzSk/qJdmVZDaZO+g=; b=esajAdA0GwBAyv80ChsNjYc1jbNOMr2ZqyscouuEI4ia+KmzEkBhAc4aim1zJB0L7d E5gW4flDfD+9c5fqpCgM0ZGxXUNT0eMeDdfaDRqA+DURDbGA2QitaCCzDdEr5EjhsRyu cn/0vpWIYQlDjvhtxSc6ZyEwD2FYhRJPJG7Ezivx/ZPqK/ze4PX70Nb+hwyz+lyt8u2f WS6JGDXgafl9LhfBO1fM2DBtNnyx0haaoBLoXRthHNmMO/P9VYI/hxKZna6gIGLkRaC8 S8iT9FPhDRSn73s6l5ghRNlNT8qYbppurHqx2DGoNAisu7KM2oYOzZWGAZzqWYerlkqM cIfQ==
X-Gm-Message-State: ALoCoQlJFsNcXLWOPQdqrDM4l7qdo4mLVh1Tdsv+FuZQIwiSKWPQCV1cBY0+OK2NjQ7YZVcQ75By
X-Received: by 10.52.134.115 with SMTP id pj19mr19280503vdb.94.1430096362834; Sun, 26 Apr 2015 17:59:22 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by mx.google.com with ESMTPSA id ms8sm21793287vdb.21.2015.04.26.17.59.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 17:59:22 -0700 (PDT)
Message-ID: <553D89E8.30100@nthpermutation.com>
Date: Sun, 26 Apr 2015 20:59:20 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Watson Ladd <watsonbladd@gmail.com>
References: <4A5C6D8F-6A28-4374-AF1F-3B202738FB1D@ieca.com> <551DDD4E.5070509@nthpermutation.com> <F7F3EB83-FEA2-477C-8810-38C49B71C977@ieca.com> <551E290D.7020207@nthpermutation.com> <55381768.8010402@nthpermutation.com> <CACsn0cm5A50dP4JDKq9R0XdB83hyzPPLQHAMnUcXFb+DCSwV7g@mail.gmail.com> <55392B08.6020304@nthpermutation.com> <CADi0yUPTixoesXkgd=HYe_+ua_+=_UfcDBSndCgdh1usTzNpzQ@mail.gmail.com> <553D3572.6040408@nthpermutation.com> <CADi0yUOnsD0Sasq7dRTbRpUm9jTg-uf+vjkkpMCxxsKXH0kqMw@mail.gmail.com> <553D79CE.1030504@nthpermutation.com> <CACsn0ck_xPbJnhKw0+wvf0G2+Me9VXvY=+DAa6xbvUGxnW0z1g@mail.gmail.com>
In-Reply-To: <CACsn0ck_xPbJnhKw0+wvf0G2+Me9VXvY=+DAa6xbvUGxnW0z1g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/PFeG_Cmr0YkeXzfMaXy-VA2klqA>
Cc: tls@ietf.org
Subject: Re: [TLS] confirming the room’s consensus: adopt HKDF PRF for TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 27 Apr 2015 00:59:25 -0000
On 4/26/2015 8:23 PM, Watson Ladd wrote: > > > If I call the HSM version of the same KDF with the same key, context > and label and tell it to produce a single HMAC-SHA256 key of length 8 > bits I will get a single byte of key stream which is identical to your > call above. Using the TLS 1.2 KDF I can even tell it to not produce > any key material but to provide me with IVs - which have the same key > stream material as from your call. All because the length and types > of the keys to be produced are not mixed into the key stream > production calculation. > > > > But the context told you what key I wanted, and how I was going to use > it. Why is that easier to enforce then one time use? I'm also not sure > why we want to protect non cert keys in an HSM: the attacker can > always use the HSM to decrypt. > This is a good question from a different direction. In general, HSMs don't do "one time use" except as buried inside compound functions (e.g. the fake key pair inside an ECDSA signature). And it may be difficult to ensure the key is zeroized before an attacker can use it. I'd rather not depend on ephemeralness as I expect different HSM implementations to deal with that differently. Doing it by getting the derivation process correct stands a better chance of getting good implementations in HSMs. In the current model, the context says how the user wants to use the key, but it doesn't constrain the HSM to use it that way or even to constrain it to produce a specific type and length of key - those are user inputs. And in TLS1.2 and before the master_secret is used multiple times. To the HSM, current TLS context is opaque unstructured data that gets mixed in without affecting the key stream to key assignment process. With respect to protecting non-cert keys: think about extracting the master secret and using steganography to hide it inside a picture on non-encrypted side of the server (or even the encrypted side if publicly available). An attacker can retrieve that, capture the traffic stream externally, derive the session keys and capture the traffic safely remote without the betraying large amount of stolen data wandering past the server interface. The attack can even forge data in the stream. This is obviously a made up example, but it was the first way I thought of using this - but consider that if an attacker can extract the master secret he can send it off to someone who can read the stream externally either in real time or later. Later, Mike
- [TLS] confirming the room’s consensus: adopt HKDF… Sean Turner
- Re: [TLS] confirming the room’s consensus: adopt … Daniel Kahn Gillmor
- Re: [TLS] confirming the room’s consensus: adopt … Nikos Mavrogiannopoulos
- Re: [TLS] confirming the rooms consensus: adopt … Dan Harkins
- Re: [TLS] confirming the room’s consensus: adopt … Russ Housley
- Re: [TLS] confirming the room’s consensus: adopt … Brian Smith
- Re: [TLS] confirming the room’s consensus: adopt … Ilari Liusvaara
- Re: [TLS] confirming the room’s consensus: adopt … Sean Turner
- Re: [TLS] confirming the room’s consensus: adopt … Sean Turner
- Re: [TLS] confirming the room’s consensus: adopt … Yoav Nir
- [TLS] confirming the room’s consensus: adopt HKDF… Peter Gutmann
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Sean Turner
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Nikos Mavrogiannopoulos
- Re: [TLS] confirming the room’s consensus: adopt … Ilari Liusvaara
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Watson Ladd
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Hugo Krawczyk
- Re: [TLS] confirming the room’s consensus: adopt … Ilari Liusvaara
- Re: [TLS] confirming the room’s consensus: adopt … Andrey Jivsov
- Re: [TLS] confirming the room’s consensus: adopt … Ilari Liusvaara
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Hugo Krawczyk
- Re: [TLS] confirming the room’s consensus: adopt … Hugo Krawczyk
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Watson Ladd
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Peter Gutmann
- Re: [TLS] confirming the room’s consensus: adopt … Salz, Rich
- Re: [TLS] confirming the room’s consensus: adopt … Michael StJohns
- Re: [TLS] confirming the room’s consensus: adopt … Hugo Krawczyk
- Re: [TLS] confirming the room’s consensus: adopt … Ilari Liusvaara
- Re: [TLS] confirming the room’s consensus: adopt … Sean Turner
- Re: [TLS] confirming the room’s consensus: adopt … Eric Rescorla