Re: [TLS] Adding an additional step to exporters

Martin Thomson <martin.thomson@gmail.com> Mon, 27 February 2017 00:28 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8B41299E1 for <tls@ietfa.amsl.com>; Sun, 26 Feb 2017 16:28:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 EBVGZz8tPSQk for <tls@ietfa.amsl.com>; Sun, 26 Feb 2017 16:28:12 -0800 (PST)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 D28CF129549 for <tls@ietf.org>; Sun, 26 Feb 2017 16:28:08 -0800 (PST)
Received: by mail-qk0-x234.google.com with SMTP id s186so75245205qkb.1 for <tls@ietf.org>; Sun, 26 Feb 2017 16:28:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o9wfkEafEPUwESlgmeUXCUpI3RJLbFmBloSFzg2KbMc=; b=PgKcyRD/ogdAIh09EjCMhgHpxwY0OsVnlsHxp++ekS9uZQrwekv/vpWQFq+4662yPt b+7zBrTkUoleVF/CuW2Ln+p9mxlVSs2m60FzSVWaF6oYa7I7tunH7WKyYUwv+A0X2nfF mr3abiP3mrncYA9fkK5lSWymeOfnBeGSYXIi4yOFzS1VRQ5HAilxq8SsLQyiCDFAkmPM J/oeDUVKtgi3Fu6hIROa4wojCxlVFzgTGnI0iFYo7b3Jot5p5FyoXN3HRiLFY/sv5Ii+ 9DMJTp5EeluWX86Hutc752jkiGkhieIbfuWqhT7gPepsGYkRs4DLwRnY0wKKLcz597T7 Bu5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o9wfkEafEPUwESlgmeUXCUpI3RJLbFmBloSFzg2KbMc=; b=MyFKeg3AxKxVira+pQ+z8Xaf0/Pf4nTCrFWCXPPMjwNxM0P9Aggp/mA1YUtXIUzyj/ Hqtk8UQQhGDWrZt+QIqyFFh7yOuSS2/cKZC0uTGyM+eUe41AsQw02g+5EQB12oLNE4en 39zohiECgfygih7SS3FigK7fT4t9Pmnrg6QsriDz8EFKojVL1/n7t0ep5aIHb+vnWDW7 TmzWuTJ+wjLgy2EM3C0hR0ApW2RABB2Y1diBMY4TBKAQbDYE4dSMhGA2SAGDcF4moWj0 wfrEfkZiSslIkME0HzNl1uxtMJKcQWQ20P9hg+FX0FjdbL38pa9ThJ9zQtIgWRsuXua0 HgUg==
X-Gm-Message-State: AMke39mRDgsy6sxfMviUBtuNokKhKq+Ajap2ktPHpM41VDALIWYTuwf5wru1yoCnFQlVR5DHaV3cvq/46U3J9Q==
X-Received: by 10.200.39.200 with SMTP id x8mr13092575qtx.159.1488155287922; Sun, 26 Feb 2017 16:28:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Sun, 26 Feb 2017 16:28:07 -0800 (PST)
In-Reply-To: <CADi0yUM4NQkj_y49Gxg6D_1CXq7sNVReaAS3XWv5C9yoqQdT2A@mail.gmail.com>
References: <CABkgnnVo0gU=jaR-qV4hypmsjVW6Vdu1RizVD0OPh0ry6vzKfQ@mail.gmail.com> <04431852-c05f-7db8-faf1-7aa622c01b75@cs.tu-darmstadt.de> <CABkgnnU2fXmh=MRANU341n+G16t=Dnt8vQeCSHV4=J=89nWBhQ@mail.gmail.com> <CADi0yUM4NQkj_y49Gxg6D_1CXq7sNVReaAS3XWv5C9yoqQdT2A@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 27 Feb 2017 11:28:07 +1100
Message-ID: <CABkgnnVhpy6fk_nZEHpV3U2E-83iD1t-JaECnjWEyhX7xg4=AQ@mail.gmail.com>
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ucRvNyJVzA8BL_1-sR6bOsjA-Fc>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Adding an additional step to exporters
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 27 Feb 2017 00:28:13 -0000

Hi Hugo,



On 25 February 2017 at 03:47, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
> Martin,
>
> Which of these two derivation schemes are you proposing?

I mean the latter of your two, where you have effectively three layers
of HKDF-Expand from the master secret.

master secret -> exporter secret
exporter secret + exporter type (label) -> specific exporter secret[label]
exporter secret[label] + context -> exporter value

(Just like what Ilari said.)

I think that is easier for implementation reasons to manage.
Splitting off from the master secret allows implementations to defer
some of the exporter-related processing and decisions until later.

> Are you assuming that all uses of the exporter_secret are known at the end of
> the handshake? If not, you still need to keep an exporter_secret beyond the
> handshake.

Yes, this is correct.  This assumes that you know the *type* of all
exporters you might support.  I think that this is a reasonable
assumption since each exporter relies on implementing a specification
for that exporter and having code for it.  For example, you might have
a list of supported exporters, for which you could derive the
intermediate value.

> Thus, both of the above possible derivations are OK from the point of view
> of HKDF.

Thanks.  I thought that it was OK, but having you confirm that makes
me much happier.