Re: [TLS] Two Decisions?

Martin Thomson <> Wed, 26 November 2014 00:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 88B851A89A9 for <>; Tue, 25 Nov 2014 16:10:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PrCHjKggZYKp for <>; Tue, 25 Nov 2014 16:10:31 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4FA5F1A89A7 for <>; Tue, 25 Nov 2014 16:10:31 -0800 (PST)
Received: by with SMTP id vb8so1364882obc.28 for <>; Tue, 25 Nov 2014 16:10:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nRgU7p4PtMKvqNQJRUE91lfDMeAm7EGliubzcvMEU5k=; b=AQ5WR5LqG2EUEAUHyDDbFokbfkqbK+lxHyv7hMzU4nPVQhBPr5Lr0pOzTcCT0PQqUT uu1WnLvajUYXLop2pK+jVemHK+H4x7DY0muQFYcvX8rgl2LG7Il/exU1KmuLH0kTQ9j2 PyCKoe9hvEXBt8VGfX1abMfcAMVidaOlC9YeHyDnqNtycROoe7H7JQJmn/IajDv3pxqS XIWI83EhtS4h0S5KuczIkWsb7YAA6E2t/jCex7KllXW/18mie7iojY8iyXjCk5acWgc5 vjhd5N2oGLTEWrVKymLIYlpera0kMTlDhw8R74JKUJgmu1A/XKelgZ0rMbJKad9dgtI3 GfSg==
MIME-Version: 1.0
X-Received: by with SMTP id ii1mr16187056obd.34.1416960630569; Tue, 25 Nov 2014 16:10:30 -0800 (PST)
Received: by with HTTP; Tue, 25 Nov 2014 16:10:30 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Tue, 25 Nov 2014 16:10:30 -0800
Message-ID: <>
From: Martin Thomson <>
To: Michael StJohns <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
Subject: Re: [TLS] Two Decisions?
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Nov 2014 00:10:37 -0000

On 25 November 2014 at 15:25, Michael StJohns <> wrote:
> A/O TLS 1.2 the PRF function changed to be negotiable.   During discussions
> for things like session hash, the question was brought up (or at least I
> brought it up) as to whether or not the PRF function always needed to be a
> hash function (vs say a block cipher function) and I think the general
> consensus was that it was too difficult to remove due to its use in the
> finish message and session hash.   Would that be a fair assessment?  And if
> so, should text be added to make this clear?  (Specifically, the PRF
> negotiation specifies a hash, and the KDF and various other derived
> functions are based on the HMAC construct of that hash.)

One of the properties we are relying on here is preimage resistance.
I believe that to be a firm requirement for exporters, for instance.
That should certainly be documented as an assumption, because it does
remove a number of MAC constructions from consideration.

The 48-byte thing always bothered me a little.  If the PRF produces
any MS that is shorter, it's not like it contains any less entropy
when talking about traffic key derivation.  I'd be inclined to say
that a single crank of the PRF is all that is needed for any of the
long-term keys, which will mean more or less than 48 depending on the
negotiated PRF.

I don't think that this is significantly more complex.  And if we are
running more PRFs, it might save a few cycles at a critical moment
(i.e., the handshake).