Re: [TLS] PRF in 1.3

Michael StJohns <msj@nthpermutation.com> Wed, 06 August 2014 18:57 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 656231B27D6 for <tls@ietfa.amsl.com>; Wed, 6 Aug 2014 11:57:58 -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 XM_1Tm89x4tf for <tls@ietfa.amsl.com>; Wed, 6 Aug 2014 11:57:56 -0700 (PDT)
Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77C5D1B27CB for <tls@ietf.org>; Wed, 6 Aug 2014 11:57:56 -0700 (PDT)
Received: by mail-qa0-f42.google.com with SMTP id j15so2992956qaq.29 for <tls@ietf.org>; Wed, 06 Aug 2014 11:57:55 -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=EFmXiWPwm0lseu7BQAIy/SJj0gJ2eMnYacH+BZU6jW8=; b=StY8CuDqtRjcd5t3pZgwaX7BitbROSiWvBurV51Cr+wRM+SrNjUvkAFEZ5TPCzsbrp pOOX4nuIgYxWLKuiMGsX2exFhZ69dDxOhtHtEOUwVbH3jJAsxAUpOfqTr+wOUzJWyjd1 zJZZdUyLbbDAUQYQ1WKrRKbd9Fwbex4mzFpuPsHF/F/83EazzZXLCaTcvb+5LdF0I4Rc SEpB0JU+IeLJ0XClT/a78hAeVQvel1+7OUavKti2ASyV8AHQhAEuK7TB1jRsHchxFHGx AKIwdbQTafFjQwe0z4XBMkhUgHJiODVMFRyzztNt9x5YY50nMjakpy5Rz7tS+z/Rbw1D az8g==
X-Gm-Message-State: ALoCoQk4vmg1lNdG8YGRhfB5DsJ+cgKFyJRppxAW+5UIzHhEo2IxzTGipCL/P5O8r/b7xCdDTYUB
X-Received: by 10.140.49.77 with SMTP id p71mr5985587qga.86.1407351475531; Wed, 06 Aug 2014 11:57:55 -0700 (PDT)
Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id 38sm1856421qgp.30.2014.08.06.11.57.54 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 11:57:55 -0700 (PDT)
Message-ID: <53E27AB6.1080809@nthpermutation.com>
Date: Wed, 06 Aug 2014 14:57:58 -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: =?UTF-8?B?SGVucmlrIEdydWJic3Ryw7Zt?= <grubba@gmail.com>
References: <201407281624.10986.davemgarrett@gmail.com> <53D9147B.1080203@nthpermutation.com> <CALuAYvbW3X4TGzhzxsaj_L_90ZR0Q6+-J4-w2QLeFaX5xC9KOg@mail.gmail.com>
In-Reply-To: <CALuAYvbW3X4TGzhzxsaj_L_90ZR0Q6+-J4-w2QLeFaX5xC9KOg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TbsqK3MDog5B8LU7piawMm8dCVA
Cc: tls@ietf.org
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, 06 Aug 2014 18:57:58 -0000

On 8/6/2014 7:43 AM, Henrik Grubbström wrote:
>> 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.
> I'd like to hear from the people that rejected P_SHA256 for the AES256
> suites in RFC 5289 (which instead use P_SHA384). I suspect that it is
> to avoid leaking the entire state of the PRF in the AES256 keys and/or
> to avoid correlation between the client-side and server-side keys.

I think this is actually not a question with respect to the KDF use of 
the PRF, but with the "PRF(k, HASH(handshake messages))" formation of 
the verify_data in the Finished messages.

HMAC_SHAXXX (k, data) is XXX bits of strength secure, but SIGN (k, 
SHAXXX(data)) (which is really what the PRF is being used for here) is 
only XXX/2 bits of strength - or so I understand from the NIST key 
management special publication.    That would place the strength of a 
suite with a PRF P_SHA256 at not greater than 128 bits for TLS1.2 and 
before.

Mike