Re: [TLS] PRF in 1.3

mrex@sap.com (Martin Rex) Wed, 06 August 2014 19:11 UTC

Return-Path: <mrex@sap.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 82FDD1A00B0 for <tls@ietfa.amsl.com>; Wed, 6 Aug 2014 12:11:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 0EFv41nFSg8p for <tls@ietfa.amsl.com>; Wed, 6 Aug 2014 12:11:25 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABE71A008F for <tls@ietf.org>; Wed, 6 Aug 2014 12:11:25 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s76JBMsK016676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Aug 2014 21:11:22 +0200 (MEST)
In-Reply-To: <53E27AB6.1080809@nthpermutation.com>
To: Michael StJohns <msj@nthpermutation.com>
Date: Wed, 6 Aug 2014 21:11:22 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20140806191122.57BC61ADF5@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3Qsu1aKlTnKpv49sFpBDWt_DIRQ
Cc: tls@ietf.org
Subject: Re: [TLS] PRF in 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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 19:11:29 -0000

Michael StJohns wrote:
[ Charset UTF-8 unsupported, converting... ]
> 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.

The PRF output is not used for in a signature style fashion.

The default signature algorithm (for combination with RSA) in
TLSv1.2 is either (sha1,rsa) or (md5,rsa), and particularly the
latter is ludicrously weak in comparison to the tlsv1.[01] (sha1+md5,rsa).

The problem with the Finished message in TLSv1.2 is that it still
truncates the PRF output to 12 bytes (96 bits).  The HMAC rfc explictly
says that one should not truncate to less than half the output size
of the underlying hash function, so TLSv1.2 **should** have used
Finished messages of at least 128 bits (16 octets) for a SHA256-based PRF,
and at least 192 bits (24 octets) for a SHA384-based PRF.

This is one of the TLSv1.2 goofs that should be fixed in TLSv1.3, btw.

-Martin