Re: [TLS] confirming the room’s consensus: adopt HKDF PRF for TLS 1.3
Michael StJohns <msj@nthpermutation.com> Sun, 26 April 2015 23:50 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 BA17A1ACDDF for <tls@ietfa.amsl.com>; Sun, 26 Apr 2015 16:50:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 Wv1I6129uu2F for <tls@ietfa.amsl.com>; Sun, 26 Apr 2015 16:50:41 -0700 (PDT)
Received: from mail-vn0-f41.google.com (mail-vn0-f41.google.com [209.85.216.41]) (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 198F61ACDFF for <tls@ietf.org>; Sun, 26 Apr 2015 16:50:41 -0700 (PDT)
Received: by vnbg7 with SMTP id g7so9983376vnb.11 for <tls@ietf.org>; Sun, 26 Apr 2015 16:50:40 -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; bh=B7sSD9wn+qdUu94oUrG679pza6Uw1h0mmiJPJJlkj9E=; b=XGel7/nzle7jR2DA8ytMRlwcRsmVDBn/1AvHQrFLHMplMzjpKtAbyl3Du14JtGNbPm dh0cCjHVPUDNW8+uiOzLRJQdDyv5/wSudBHHcl7ByJbGupF2je0EHQLdJ4R0JdP4q6Dv 3g4a+KvmVTlljYy6jBdWrvj3R5D0UqBLmvKn6PZ0FPvHpsORMQ0sV5pxg0OFAF4xevNe ki/e0cZrObC9Tx7HAvUbRBWPdiMz5WTzOb2xYZ60FTxpy9gN8velP61SRLG5zcQbEwVa +Q0t2HehNZmv/g6UDzMpgwcGW8SNbNkprM+78Lwi9py1NI19G6INRBTLioIyDjpSqVt/ k3Zg==
X-Gm-Message-State: ALoCoQn4YN5y7nORB0tz8eXz9If75ZiPmgiXMPFMYCM4rOfVVuGBLnrCoI0CKZ+4b7NkLGtR0eQ5
X-Received: by 10.52.3.10 with SMTP id 10mr21612883vdy.74.1430092240286; Sun, 26 Apr 2015 16:50:40 -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 j9sm21418066vdi.28.2015.04.26.16.50.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 16:50:39 -0700 (PDT)
Message-ID: <553D79CE.1030504@nthpermutation.com>
Date: Sun, 26 Apr 2015 19:50:38 -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: Hugo Krawczyk <hugo@ee.technion.ac.il>
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>
In-Reply-To: <CADi0yUOnsD0Sasq7dRTbRpUm9jTg-uf+vjkkpMCxxsKXH0kqMw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------000801010009020508020903"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/PQyPxf_fkVyx39KEl3GA_dYXwVE>
Cc: "tls@ietf.org" <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: Sun, 26 Apr 2015 23:50:42 -0000
On 4/26/2015 4:20 PM, Hugo Krawczyk wrote: > > TLS1.2 uses the Master secret as a key for both the MAC and KDF > functions and that needs to change. Those can't be the same key - > and hence your comment about using the same master secret for > different derives becomes problematic especially if one of the > outputs is to an exporter. > > > The same Master Secret is used to derive multiple keys but these are > derived with unique label+context input. > > Different derivations *never* use the same label+context. Next part of the discussion. Pretend you're implementing this in an HSM. How does the HSM enforce the "never use same label and context"? Answer is that it can't and there isn't anything currently defined in the label or context that allows the HSM to do proper policy protection. What needs to happen here is to include in the calculation of the key stream sufficient values to ensure the key stream is completely different if the requested output (e.g. target keys and types) of the key stream is different. Consider as an HSM input to the TLS KDF the label "key expansion", the handle for a specific master_secret key and the client and server randoms concatenated as the context. Internally, the HSM will concatenate the label and context into what you call "info". The last set of inputs to the "key expansion" call to the KDF are the types and output lengths of the key material, but those aren't involved in the calculation of the key stream. If you call the HSM version of the KDF with a key, context and label and tell it to break things into 2 keys (for AES-CCM) of length 256 bits each you will produce a key stream of length 64 bytes. 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. If I define the TLS KDF as HKDF with a context consisting of (from my now expired draft): struct { uint8 clientRandom[32]; /* ClientHello.random */ uint8 serverRandom[32]; /* ServerHello.random */ uint32 keyCount; /* Num keys to derive */ KeyType keyTypes[keycount]; uint16 keyLengths[keycount]; /* Key lengths in bits */ } KeyExpansionContext; the HSM can use the key types and lengths to enforce policy of key assignment. An attacker can no longer assign a part of the key stream to shorter keys since the key stream changes if the length of any subkey changes. It can no longer assign a strong mechanism key to a weaker mechanism because if the key type changes so does the key stream. After discussions on the list, I'd probably also add a uint16 of flags per key to allow for some keys to be exported (and allow the HSM to know which ones are exportable). There are other issues, but this gets us closer. 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