Re: [TLS] PRF in 1.3

Michael StJohns <msj@nthpermutation.com> Wed, 30 July 2014 15:52 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 5C59D1A00E9 for <tls@ietfa.amsl.com>; Wed, 30 Jul 2014 08:52:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DcgFCkVd4umB for <tls@ietfa.amsl.com>; Wed, 30 Jul 2014 08:52:06 -0700 (PDT)
Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7F51A00D8 for <tls@ietf.org>; Wed, 30 Jul 2014 08:52:06 -0700 (PDT)
Received: by mail-qg0-f45.google.com with SMTP id f51so1743407qge.18 for <tls@ietf.org>; Wed, 30 Jul 2014 08:52:05 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DRKmhhGAWtnR05KFXkqUrvkM4UhVColGAz9Q94CuhQI=; b=AMCEPYfpz/7HvnZOmno9u8grotd9F+TeyE3bq7QDNWBNpv0yrHkdMKejtWB/S9qgn1 AgSVnmBfm7Dbwo4YCT1JvMLS/I4Hwi60sducjwaQ7OfuFIiStFjLy0CIryHQ/5M1NA4B bGr4XLZMlD/A6Z7l95jwmg3jOHXsRvTQeV1V39GSO/J6Go4uz4TnyQBCuIqWJblYtymr d8UOuB0RR+iLOzszAICheeR9UoGUImnZkaRt734thEF46UvwUiWDW+CUmulEMBLaxGxy mf3z2LQg4XLmo/lIND3jgndCt+mi5YosExuPRzjxqLp+U2f0k5IT2enGfVmzBY3DOYFW u94g==
X-Gm-Message-State: ALoCoQl/w0jZZs0c4KK3kWUShd6N8NOR+Ht/YiCtE/9NWw38xYmNk0i7Y+otSiMx6MkTH5zEOXqh
X-Received: by 10.140.88.243 with SMTP id t106mr5505428qgd.12.1406735525138; Wed, 30 Jul 2014 08:52:05 -0700 (PDT)
Received: from [192.168.1.111] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id s11sm4623743qag.12.2014.07.30.08.52.04 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 08:52:04 -0700 (PDT)
Message-ID: <53D9147B.1080203@nthpermutation.com>
Date: Wed, 30 Jul 2014 11:51:23 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: tls@ietf.org
References: <201407281624.10986.davemgarrett@gmail.com>
In-Reply-To: <201407281624.10986.davemgarrett@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VWLl9Ezdb9Gp7x9y1U_5KiXmXNI
Subject: Re: [TLS] PRF in 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: Wed, 30 Jul 2014 15:52:12 -0000

On 7/28/2014 4:24 PM, Dave Garrett wrote:
> https://github.com/tlswg/tls13-spec/issues/26
>
> Issue #26 notes complication with the usage of a negotiable PRF. The
> current suggestion mentioned was to consider removing PRF
> negotiation in favor of SHA-256, calling it "good enough" until the next
> protocol version. I agree that this is quite possibly the case, however
> I would like to suggest future proofing things a bit. Old versions of TLS
> used the strategy of dual hash algorithms "to ensure that
> non-catastrophic flaws in one algorithm will not break the overall
> protocol" [RFC4346 F.1.5]. TLS 1.1 used MD5+SHA1. For TLS 1.3, I
> would like to suggest SHA2-256+SHA3-256 or similar for consideration.
> Picking a single combo allows the removal of negotiation, fixing any issues
> that causes, provides a simpler spec for this feature, and allows both the
> current standard and new SHA functions to be used without having to
> rely 100% on either. Adoption rates of new TLS versions are less than
> ideal, so future proofing in manners like this that don't add a fantastic
> amount of additional complexity seems like an idea worth consideration.

I don't believe this is the right place to start asking the questions.  
Instead, let's look at where the PRF is used and in what context, and 
then figure out whether or not what we have is good enough.

TLS uses three (or four) logical constructs during handshaking - a key 
derivation function (1) to derive the master secret from the premaster, 
and the session keys from the master secret; a MAC function (2) to 
"sign" the handshake (Finished message verify_data), and a pseudo-random 
data generator (PRDG) (3) to generate coordinated IVs and nonces for 
some crypto suites.  There's also the hash function (4)  used to 
summarize the handshake prior to it being signed.  (3), in TLS1.2 and 
before, is a generated as part of key stream derived from the master secret.

All of these constructs except the hash use the keyed TLS PRF (a keyed 
recursive HMAC PRDG function), but the hash function is currently the 
same as the underlying hash function for HMAC in the TLS PRF.

So breaking it down:

Is (1) secure enough to derive keys?   The construct used in TLS is 
similar to the section 5.2 construct of NIST SP800-108.  But the SP800 
construct has one extra piece missing from this one - the L parameter 
which ensures that the key stream changes if the number of output bits 
change.  There's also expanded guidance on the context field - the 
equivalent values in TLS are currently just the client and server 
random.   I've got some issues with that - see 
http://tools.ietf.org/html/draft-stjohns-tls-tls13-crypto-infra-00, and 
I would add information about the types and lengths of the keys to be 
derived from the key stream to the context.  With those changes, a 
recursive based HMAC PRDG at the heart of the KDF is probably 
sufficiently secure for key derivation going forward.

Is (2) secure enough to sign the handshake? (2) is probably overkill in 
its current state.  It also uses the TLS PRF and should instead just use 
the HMAC - there's no added security using the TLS PRF. There is another 
issue with the fact that the master secret is used to key both (1) and 
(2) - that's generally considered bad cryptographic practice.

Is (3) secure enough to generate IV and nonce data?  (3) is probably 
overkill.  It uses the master secret to key the PRDG.  Discussions with 
various folks as well as perusing the literature suggest that a key of 
'0's used with the client and server random as context data is 
sufficient as all is needed is an extraction of entropy from other 
random values.   This is NOT a random data source in the general 
cryptographic meaning, but a way of getting the same public data out on 
both sides simultaneously without needing to include them in the 
handshake.  There is a current issue with this in that the master secret 
is used to key this function as well as (1) and (2).

In general, (1), (2), and (3) are probably secure if the TLS PRF 
recursive HMAC is secure, and that's probably secure (if the issues 
above are addressed) assuming (4) is secure.

Is (4) secure enough?  The general comment is that you can negotiate a 
better one if (4) isn't secure.  However, the hash is necessary to 
summarize the handshake because the key for (2) isn't available to the 
server until a substantial portion of the handshake has been 
sent/received. If the client is trying to negotiate a new hash, then the 
client will need to maintain separate hash contexts until it gets the 
server acknowledgement of the hash (PRF) selection and can throw the 
ones it won't use for that away.

The requirements for (2) (key not available until later) argues that the 
TLS PRF has to continue to be built on a hash function unless the data 
signed by (2) changes.  The discussion for (4) suggests that we can't 
just say that SHA256 will always be the value.


Mike


>
>
> - Dave
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>