IETF Logo Mail Archive

Re: [TLS] HKDF

Eric Rescorla <ekr@rtfm.com> Wed, 25 March 2015 19:12 UTC

Return-Path: <ekr@rtfm.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 F3BFA1A9055 for <tls@ietfa.amsl.com>; Wed, 25 Mar 2015 12:12:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 yE4lmYcrNiyI for <tls@ietfa.amsl.com>; Wed, 25 Mar 2015 12:12:54 -0700 (PDT)
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E621A89A3 for <tls@ietf.org>; Wed, 25 Mar 2015 12:12:54 -0700 (PDT)
Received: by wixw10 with SMTP id w10so52689634wix.0 for <tls@ietf.org>; Wed, 25 Mar 2015 12:12:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=A/bdyjT8kqWbuasm/MW/QFzSRLMXBQL0TpmlwZ6EOak=; b=AKCmcHhNhdakvZOCeQqnMUf1H+tjOMpB8DUfz+fUq3Hflkmgo3Ka33evXTKMkuopSi OxY4+b6McLx/406DH01pzPuVmxsbcYL7GJfcV/em0+w4sH2KYVMm0rKbp6rbMMnTLzJa 9tLO1qcnFkt77zGX4wCFndXVRTpA1LiBsBwDDVu0UpBhGcj9vMKgcI/V4XQwYZ8Uv6Fg XBQNsniNj+5icrJ4/pewn33ZRmCEcsQjH/NBrYhe/PGmh1cQtqLoRZRXEsMWueTfeN9o 83+IaCXKlF3Xz93Xn7R9ZbCWFPHIM2+C1cvYusqTSFJd2txMu40JUwGA6VJFL860cAST bN4w==
X-Gm-Message-State: ALoCoQmKQ7kWbOxNcNyqLYNGcWGuLEKaVRci9Oa8TC5PLJ0id+bU1m7nYP93WwZwmxN5RrPF+u+m
X-Received: by 10.180.84.99 with SMTP id x3mr22276760wiy.35.1427310773013; Wed, 25 Mar 2015 12:12:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.205.198 with HTTP; Wed, 25 Mar 2015 12:12:12 -0700 (PDT)
In-Reply-To: <CAFewVt5aNnQB6JseSjpMiox=Sxa7bHpdqsNcBU230ObgZwcX_Q@mail.gmail.com>
References: <CABcZeBPa3j+EfMkPik7r5G-qcBpYkXTFWwYwuCeE38mFjUwpJw@mail.gmail.com> <CAFewVt5aNnQB6JseSjpMiox=Sxa7bHpdqsNcBU230ObgZwcX_Q@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 25 Mar 2015 14:12:12 -0500
Message-ID: <CABcZeBNKi9aKp1AJWGBeq3bzqKve1QH-vTo4qcTPwgJd87xBQw@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: multipart/alternative; boundary="f46d044403a89c20a4051221afba"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/FFLErAcuEqjvNh1zLRIJZy9SCLM>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] HKDF
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, 25 Mar 2015 19:12:56 -0000

On Wed, Mar 25, 2015 at 1:47 PM, Brian Smith <brian@briansmith.org> wrote:

> Eric Rescorla <ekr@rtfm.com> wrote:
> > As I mentioned in a previous message [0] during the interim we discussed
> > moving from the TLS PRF to HKDF [RFC5869].
> >
> > The general sentiment was:
> >
> > - Move to HKDF
> > - Specify both SHA-256 and SHA-384 (the latter being required for
> >   Suite B)
>
> Assuming that the choice of either SHA-256 or SHA-384 is fixed per
> cipher suite, as is the case with TLS 1.2, switching to HKDF seems
> like a good idea to me.
>
> > This is also the time when we would want to look at adjusting
> > the key expansion to separate keys and IVs (assuming we still
> > have IVs).
>
> If the IVs are secret (only shared between the two peers) then I don't
> see the need to change how they are calculated from the keyblock.
>

The issue is that in many cases the IV will be handled outside the crypto
module, and the keys should stay inside the crypto module. The traditional
slice and dice makes that hard.

-Ekr

v2.23.0 | Report a Bug | By Email