Re: [TLS] Computation of static secret in anonymous DH

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Fri, 26 June 2015 08:50 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 746551A0276 for <tls@ietfa.amsl.com>; Fri, 26 Jun 2015 01:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 8BvEeZQ3Vafa for <tls@ietfa.amsl.com>; Fri, 26 Jun 2015 01:50:16 -0700 (PDT)
Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339691A0469 for <tls@ietf.org>; Fri, 26 Jun 2015 01:50:12 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 91BA01A2655; Fri, 26 Jun 2015 11:50:09 +0300 (EEST)
Date: Fri, 26 Jun 2015 11:50:09 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20150626085008.GA25187@LK-Perkele-VII>
References: <2AA11887-2F82-48EF-BD45-4D85CFA83847@qut.edu.au> <20150617082529.GA17280@LK-Perkele-VII> <CABcZeBNzzfxo+xQRrS=7-7C65kr3DqtJ5BHqTnt0mC8v-oFuUw@mail.gmail.com> <20150617150505.GA19959@LK-Perkele-VII> <CABcZeBN8m6f=F14Qx1QctMCoF7_LYNrf9D3HstoTZsK2orS1SA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABcZeBN8m6f=F14Qx1QctMCoF7_LYNrf9D3HstoTZsK2orS1SA@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/8kUR3rOZC-Py2TKEWNTMCUld7NE>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Computation of static secret in anonymous DH
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: <https://mailarchive.ietf.org/arch/browse/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, 26 Jun 2015 08:50:21 -0000

On Wed, Jun 17, 2015 at 09:35:14AM -0700, Eric Rescorla wrote:
> On Wed, Jun 17, 2015 at 8:05 AM, Ilari Liusvaara <
> ilari.liusvaara@elisanet.fi> wrote:
> 
> > On Wed, Jun 17, 2015 at 05:56:23AM -0700, Eric Rescorla wrote:
> > > On Wed, Jun 17, 2015 at 1:25 AM, Ilari Liusvaara <
> > > ilari.liusvaara@elisanet.fi> wrote:
> > >
> > > > There's much newer version in ekr/tls13-spec#WIP_draft_06
> > > > (seems to have fixed most of the mistakes in the original WIP)
> > > >
> > >
> > > Don't worry, I'm sure there are plenty of mistakes left!
> >
> > Such as how keys for TLS exporters are derived?
> 
> Quite possibly. Hence the WIP designation.
> 

Reviewing it again after changes (e1219310a7f, Jun 25th):

1) xSS is used as direct input to HKDF-Expand, so one would presume
it should be HKDF-Extract output (AFAIK, HKDF-Extract and HKDF-Expand
are supposed to be paired). HKDF-Extract does not take label nor
length.

2) Same as above for xES.

3) Same as above for master_secret.

4) Why does master_secret derivation take xSS and xES instead of
SS and ES directly (especially if xSS and xES are supposed to be
HKDF-Extract outputs)?

4) Why is finished independent of ES (IIRC, it did depend on it
in earlier version)?

5) Application data uses xES as secret. AFAICT, leads to an attack.
Should be master_secret (IIRC, was that way in earlier version)?

6) I think the key table should refer to inputs by their proper
names, not e.g. referring to "xES" as "ES" when there is another
thing named "ES" (that's confusing even with a note).

7) I think there should be helper function defined to do the
label zero-padding, instead of it being just a note (just for
clarity).


-Ilari