Re: [TLS] Two Decisions?

Martin Thomson <martin.thomson@gmail.com> Wed, 26 November 2014 00:10 UTC

Return-Path: <martin.thomson@gmail.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 88B851A89A9 for <tls@ietfa.amsl.com>; Tue, 25 Nov 2014 16:10:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrCHjKggZYKp for <tls@ietfa.amsl.com>; Tue, 25 Nov 2014 16:10:31 -0800 (PST)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FA5F1A89A7 for <tls@ietf.org>; Tue, 25 Nov 2014 16:10:31 -0800 (PST)
Received: by mail-ob0-f169.google.com with SMTP id vb8so1364882obc.28 for <tls@ietf.org>; Tue, 25 Nov 2014 16:10:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.183.24.129 with SMTP id ii1mr16187056obd.34.1416960630569; Tue, 25 Nov 2014 16:10:30 -0800 (PST)
Received: by 10.202.115.4 with HTTP; Tue, 25 Nov 2014 16:10:30 -0800 (PST)
In-Reply-To: <54750FDC.5040909@nthpermutation.com>
References: <54750FDC.5040909@nthpermutation.com>
Date: Tue, 25 Nov 2014 16:10:30 -0800
Message-ID: <CABkgnnXdg1ibcFuMguDoevwFrogxpaF8CvhS6qUXGoTP9KRoLQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Michael StJohns <msj@nthpermutation.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IGr50PmAEB5-NenkcxL-tCu1h38
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Two Decisions?
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, 26 Nov 2014 00:10:37 -0000

On 25 November 2014 at 15:25, Michael StJohns <msj@nthpermutation.com> 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).