Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519

Martin Thomson <martin.thomson@gmail.com> Mon, 09 May 2016 00:23 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73E912D0F3; Sun, 8 May 2016 17:23:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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] 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 C7yZvoytjstO; Sun, 8 May 2016 17:23:32 -0700 (PDT)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 4B90812D0EC; Sun, 8 May 2016 17:23:32 -0700 (PDT)
Received: by mail-ig0-x231.google.com with SMTP id m9so80260071ige.1; Sun, 08 May 2016 17:23:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ZBISGrfzHA7AV099u8a+TLmyXf5Q0l+TjwBRrE9/IhE=; b=Bd8EixREZ5o4gE7etE+Ju0cuZykqQWaWzIDcAGwsxfXyOmqgC1SS1EtI/vodu51beg JKZ5cWmVJK/nF/Sbm27DxlFqF88KNk0xL5LzSk1bWT0hZz77xpuM+kZOMxnplXYF5TNz sbDiNIlizD3mJl4auH0w5zsDS17P5MsAX9uvac5fe5x8u2USwV5sdC3MZ44rpCfK0ubk N7LIKybLN9b4oSIJf5ef2ED+UWVpCmR8iHDgiq4VeJK6tO2TwUtX3LzonXIRJfSsGaEQ dPhg/+EhWv5Gq48PB2cyBFGL07e46Qf9VpU1BD2/sqfhoLSL3H+nBR5hRIin4igDxK0I ThwQ==
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:date :message-id:subject:from:to:cc; bh=ZBISGrfzHA7AV099u8a+TLmyXf5Q0l+TjwBRrE9/IhE=; b=ETaW/eBXr392Xu533+Ygneu2CuEJrSg4Jlj8x6H+EJ7BYFD1fVcyXSt44LHqh8gDAe Ab81F3yodsXQwUC3sdOTiZ/ArOb265ZaVhwc03FbZaSNxeKrDFZZcwmOf1TTO4JN5HCc BsBlqQsO6iifweQB2oBDz6nLH7VSMoAWgxgooJPkHF5mcxXQn21Pcd6wZDC/V72jWBdR Ca/3GJSltBBx3xlBezb2nToyzMKMYtUrHGO16tqKdsEQe72QATXBT4StV5eBX1YZZznd rklg2YCD+MuMCUFrs49QpvQzv5/gmIqJ8+AzI0kIMTBsTwl4bdoPmfD+EsHedvy8xiPl 0JzA==
X-Gm-Message-State: AOPr4FX6BhjCtcB5kMGqwHAlENh4NeAu0vyiHhf07vAZsARN3KSGQXlUbqacWB9iEkifooeyDJ1lRhXdCanXdg==
MIME-Version: 1.0
X-Received: by 10.50.33.81 with SMTP id p17mr8479353igi.58.1462753411702; Sun, 08 May 2016 17:23:31 -0700 (PDT)
Received: by 10.36.43.82 with HTTP; Sun, 8 May 2016 17:23:31 -0700 (PDT)
In-Reply-To: <20160506101733.GA2552@LK-Perkele-V2.elisa-laajakaista.fi>
References: <87bn543id1.fsf@alice.fifthhorseman.net> <87zisk94bg.fsf@latte.josefsson.org> <871t5wxfs4.fsf@alice.fifthhorseman.net> <87d1ozvfak.fsf@latte.josefsson.org> <20160506101733.GA2552@LK-Perkele-V2.elisa-laajakaista.fi>
Date: Mon, 09 May 2016 10:23:31 +1000
Message-ID: <CABkgnnVDDoh1t-GA54b31X9GVGTyFHtjNjEhzMaGdCHkFNNO6g@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/wkc2a9NTPV1mZ8-ICrgG7wQHEF8>
Resent-From: alias-bounces@ietf.org
Resent-To: <>
Cc: Simon Josefsson <simon@josefsson.org>, cfrg@ietf.org, draft-irtf-cfrg-eddsa.all@ietf.org
Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 May 2016 00:23:34 -0000

On 6 May 2016 at 20:17, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
>
> So yeah, just use separate keys. Don't cause problems for everybody
> by using contexts.

As an author of a document that defines the use of contexts, how do
you reconcile this view with what the document says?

I agree with the idea that there is a moral superiority in using
different keys.  That's an inarguable statement from a position of
great integrity.

djb's one-bit protocol examples highlight that there is an inherent
futility in attempting domain isolation at any layer of a protocol
stack that might conceivably be used in support of some high-layer
protocol.

But I see those examples as illustrative of an insufficient degree of
redundancy.  For, if ever there were fans of redundancy, it would be
the military.  While conceivably you could build a protocol that
defers all self-identification and context to the crypto that supports
it, in the cases illustrated, it shows itself as unwise in the extreme
in light of the propensity of people to do bad things.

We find that reuse of signature keys for different purposes is rife in
the real world.  A firm requirement of TLS 1.3 is that existing keys
can be used with the new protocol.  It would not deploy otherwise, and
yet we endorse that which we all agree to be a sin and do what we can
to avoid problems.

When signature keys are used to identify, I predict that they will
definitely be misused in this fashion.  I've seen it many times
already, and don't imagine that any edict from the CFRG will change
that.

I disagree with the notion of there being "serious" or "fundamental"
usability problems.  You are correct in that these are not perfect
bijective mappings from one domain to another, particularly when there
are existing users of the signature scheme.  However, you are
perfectly reasonable in noting that people are using Ed25519 and so
suggesting that they instead use some newly defined Ed25519ctx for
some marginal benefit (domain separation) is not in their interests.

Take the suggestion for what it is: a backstop for when good sense fails.