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

"D. J. Bernstein" <> Mon, 23 May 2016 08:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DAE9312D64F for <>; Mon, 23 May 2016 01:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EpaccyMTTbHJ for <>; Mon, 23 May 2016 01:22:41 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id D223612D60D for <>; Mon, 23 May 2016 01:22:40 -0700 (PDT)
Received: (qmail 21320 invoked by uid 1017); 23 May 2016 08:23:03 -0000
Received: from unknown (unknown) by unknown with QMTP; 23 May 2016 08:23:03 -0000
Received: (qmail 27028 invoked by uid 1000); 23 May 2016 08:22:30 -0000
Date: Mon, 23 May 2016 08:22:30 -0000
Message-ID: <>
From: "D. J. Bernstein" <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <>
Resent-To: <>
Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 May 2016 08:22:43 -0000

Bryan Ford writes:
> better than if there was no context parameter.

Applications that share keys are very likely to copy this parameter, for
the same reasons that they pretty much always end up copying MIME types.
The benefits you're referring to are limited to cases where applications
share keys but manage to stick _more_ information into this parameter
than they would have stuck into the message itself.

Meanwhile everyone ends up suffering through bottom-to-top complications
in the signature API. This is, in particular, a drag on auditing, and
it's going to end up taking resources away from auditing and fixing the
hard cases of cross-protocol attacks, very much the same way that a pile
of well-intentioned complications to the X.509 certificate format ended
up taking resources away from what we _need_ to do with certificates.

> in any IETF-defined protocol in the future that specifies that the
> context parameter must be “FOO”

The IETF-defined protocols can just as easily use prefixes---in fact,
more easily, because then they simply work with _all_ signature systems
rather than just systems supporting the committee API.

Nobody is objecting to having signature users coordinate message
semantics (especially if they're sharing keys!). Nobody is objecting to
having a central registry of prefixes. But this doesn't need a new API,
and there are many other reasons to object to a new API.