IETF Logo Mail Archive

Re: [TLS] HKDF

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Thu, 26 March 2015 07:24 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
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 539BC1B2C0C for <tls@ietfa.amsl.com>; Thu, 26 Mar 2015 00:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 PtR9-iTgZztN for <tls@ietfa.amsl.com>; Thu, 26 Mar 2015 00:24:43 -0700 (PDT)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57E51A7002 for <tls@ietf.org>; Thu, 26 Mar 2015 00:24:42 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 928F99006D; Thu, 26 Mar 2015 09:24:40 +0200 (EET)
Date: Thu, 26 Mar 2015 09:24:40 +0200
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Brian Smith <brian@briansmith.org>
Message-ID: <20150326072440.GB6108@LK-Perkele-VII>
References: <CABcZeBPa3j+EfMkPik7r5G-qcBpYkXTFWwYwuCeE38mFjUwpJw@mail.gmail.com> <CAFewVt5aNnQB6JseSjpMiox=Sxa7bHpdqsNcBU230ObgZwcX_Q@mail.gmail.com> <CABcZeBNKi9aKp1AJWGBeq3bzqKve1QH-vTo4qcTPwgJd87xBQw@mail.gmail.com> <CAFewVt57_XdbXR71ORyF-w1shXKYqsUpYfkEBC1_SFyf0Rv9jw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAFewVt57_XdbXR71ORyF-w1shXKYqsUpYfkEBC1_SFyf0Rv9jw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/po8PfmE6T7EQnBzmeUhF5xNpWvc>
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: Thu, 26 Mar 2015 07:24:44 -0000

On Wed, Mar 25, 2015 at 04:36:02PM -1000, Brian Smith wrote:
> Eric Rescorla <ekr@rtfm.com> wrote:
> > On Wed, Mar 25, 2015 at 1:47 PM, Brian Smith <brian@briansmith.org> wrote:
> >> 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.
> 
> Conversely, if the crypto module *doesn't* work like that, then it
> isn't clear to me that it is actually offering a useful amount of
> protection of the key material. It doesn't seem useful to make things
> more complicated in order to support that kind of design, which seems
> broken.

Turns out you can't even implement TLS fully in design that does not
know about TLS, nor does it seem one can even change TLS so that
would be possible (at least without introducing gaping security holes).



-Ilari

v2.23.0 | Report a Bug | By Email