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

"D. J. Bernstein" <> Sat, 21 May 2016 13:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 52BF912D0C9 for <>; Sat, 21 May 2016 06:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Z99x6lR5R9NM for <>; Sat, 21 May 2016 06:57:52 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 48A1912B030 for <>; Sat, 21 May 2016 06:57:51 -0700 (PDT)
Received: (qmail 13667 invoked by uid 1017); 21 May 2016 13:58:16 -0000
Received: from unknown (unknown) by unknown with QMTP; 21 May 2016 13:58:16 -0000
Received: (qmail 10786 invoked by uid 1000); 21 May 2016 13:57:44 -0000
Date: Sat, 21 May 2016 13:57:44 -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: Sat, 21 May 2016 13:57:54 -0000

Bryan Ford writes:
> While the same domain-separation benefit can always be achieved by
> just prefixing the message, having an explicit context parameter in an
> API forces the software developer who’s calling that API to see it,
> and think “do I need to pass something there? what? should I ask a
> colleague?”

And so they copy and paste code from somewhere else, or (if they're in
control of both ends) try the empty string, which works, the same way
that most protocols built on top of DNS are identified in DNS as "TXT".
How do you imagine most programmers being successfully pressured to
create a new "context" whenever the message semantics change: library
revisions, for example, or state modified by previous messages?

If you think you're solving the fundamental cross-protocol security
problems that I described in "Side inputs to signature systems, take 2",
then let me suggest that you follow up in detail to that message. I see
your proposed bottom-to-top API revision as a distraction from the core
task of developing secure message semantics.

We already have too many file-type systems. Most of them were designed
out of complete disregard for previous work; we definitely don't need
more of these. Efforts to define semantics via oversimplified metadata
tags (DOS file types, for example, and MIME types) have always ended up
being supplemented by more flexible mechanisms to define semantics
inline (MP4, for example, and XML). People build software-dispatch
mechanisms around metadata tags and then end up having to build more
flexible software-dispatch mechanisms to handle subtypes declared
inline. Programmers are constantly fighting multiple API layers for
something that could and should have been handled with just one layer.

>From a security perspective there's even more importance to specifying
semantics clearly; it's even more clear that these semantics depend on
application-specific dynamic context; and we _definitely_ don't want
unnecessarily complicated APIs. Separate tags have historically proven
to be inferior to inline mechanisms in all of these dimensions.