Re: [TLS] HSM-friendly Key Computation

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Fri, 24 April 2015 05:19 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 3B83E1B2CE3 for <tls@ietfa.amsl.com>; Thu, 23 Apr 2015 22:19:05 -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 bXC3HpgMYhzA for <tls@ietfa.amsl.com>; Thu, 23 Apr 2015 22:19:02 -0700 (PDT)
Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A751B2CBA for <tls@ietf.org>; Thu, 23 Apr 2015 22:18:32 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id E4A0F410E; Fri, 24 Apr 2015 08:18:29 +0300 (EEST)
Date: Fri, 24 Apr 2015 08:18:29 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20150424051829.GA3821@LK-Perkele-VII>
References: <CANeU+ZAL6oT6tP7OcL_8j6kp4oZB9V89R-0PrCdv-N27qVb0HQ@mail.gmail.com> <20150420163755.GA15511@LK-Perkele-VII> <5537D43A.9080802@REDHAT.COM> <20150422173526.GA14496@LK-Perkele-VII> <CABcZeBPN33DM_C0sAmCTFCTdNrcQ7y7eEBcZgPe+2f1EaxtXzA@mail.gmail.com> <55381302.5030307@nthpermutation.com> <20150423084201.GA21246@LK-Perkele-VII> <CABcZeBMcy_C0TWgOfw6480ZV28GTfEsgABf5b9-hKPbRGkTCMQ@mail.gmail.com> <20150423110214.GA21716@LK-Perkele-VII> <CABcZeBNPmssXgLW70Kk+v3rELaYbar_rkdDZAexYoshXoDAm-A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABcZeBNPmssXgLW70Kk+v3rELaYbar_rkdDZAexYoshXoDAm-A@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/m2KyD8Gd3ylvEWm4-waDvq7Bo6k>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] HSM-friendly Key Computation
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: Fri, 24 Apr 2015 05:19:05 -0000

On Thu, Apr 23, 2015 at 04:05:52PM -0400, Eric Rescorla wrote:
> On Thu, Apr 23, 2015 at 7:02 AM, Ilari Liusvaara <
> ilari.liusvaara@elisanet.fi> wrote:
> 
> > On Thu, Apr 23, 2015 at 05:54:02AM -0400, Eric Rescorla wrote:
> 
> Can you explain what you mean by "perturbs"? If you include the session hash
> it includes the randoms.

HKDF RFC seems to essentially say 'if you can use salt, do so'

> > If you're referring to how we combine (say) the static DH and the
> > ephemeral
> > > DH, what we had discussed was running K1 through HKDF-Extract to
> > > generate PRK1 and then using PRK1 as the salt for HKDF-Extract on
> > > PRK2. I.e.,
> > >
> > >    PRK1 = HKDF-Extract(0, K1)
> > >    PRK2 = HKDF-Extract(0, K2)
> >
> > AFAIK, nobody really uses FixedDH. And I think it was Adrei Popov who
> > described how to do 0RTT in simpler way.
> >
> > Also, maybe the only interesting application of FixedDH is deniable
> > key exchange. Except that supporting that would cause major issues
> > elsewhere (and "DH based key exchange" is not deniable).
> 
> 
> It's not FixedDH, it's the servers semi-static DH and the client's
> ephemeral.

Which semi-static DH (x client's ephemeral)?
- Current
- Previous (may not be available!)
- Both

For current, the only even semi-sane use I can come up with is server
fixedDH certs (this input not a good place to stick PSKs if one wants
"unified" something).

For previous, it is useful if 0RTT group can differ from main exchange
group (but server has to signal if this is to be included or not, since
it may not be computable).

(And both for when both of above apply).


Also, it occurs to me that trying to stick keying data into non-key
PRF inputs may not be a good idea...

And the signature looks more complicated in draft "DH based key exchange",
because the params are in the same message as certificate verify, instead
of separate message (where hash would get it instead of having to be
included separatedly).


-Ilari