Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 20 April 2016 22:12 UTC
Return-Path: <dkg@fifthhorseman.net>
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 BC1F112DF1C for <cfrg@ietfa.amsl.com>; Wed, 20 Apr 2016 15:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 YuLycIsfsIEk for <cfrg@ietfa.amsl.com>; Wed, 20 Apr 2016 15:12:07 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5E91212DD6C for <cfrg@ietf.org>; Wed, 20 Apr 2016 15:12:07 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 289E7F991; Wed, 20 Apr 2016 18:12:05 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id EEA9020061; Wed, 20 Apr 2016 18:12:05 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: "D. J. Bernstein" <djb@cr.yp.to>, cfrg@ietf.org
In-Reply-To: <20160420205120.28700.qmail@cr.yp.to>
References: <20160420205120.28700.qmail@cr.yp.to>
User-Agent: Notmuch/0.21+128~g620f892 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Wed, 20 Apr 2016 18:12:05 -0400
Message-ID: <878u080w22.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/WJl2hbu2HvN7w24cjfpbXCEZEMk>
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: Wed, 20 Apr 2016 22:12:09 -0000
On Wed 2016-04-20 16:51:20 -0400, D. J. Bernstein wrote: > I sent CFRG a message "Side inputs to signature systems" back in > September that raises several different objections to the "context" > concept. I believe that all of the objections remain valid. I didn't > notice until now that the concept was still under consideration; sorry! The context label is explicitly in place in Ed448 in the current draft, but not in Ed25519. Your concerns are reasonable, but i don't think they're insurmountable or that they warrant the removal of Ed448: > * Are cryptographic libraries supposed to change their signature > APIs to allow an extra side input? A library that implements a signature scheme that has a context string needs to provide an API for it, yes. For signature schemes where the context string is optional (which is all of them, afaict), the context label should be optional. Libraries that implement such a scheme can continue to offer the traditional API (without a context label) of course. We've already seen some primitives adopt this approach, including the "info" parameter for HKDF-Expand (https://tools.ietf.org/html/rfc5869#section-2.3). This isn't a traditional asymmetric signature scheme, but it's an addition to the API compared to earlier KDFs (e.g. PBKDF2 didn't have such a context label). > * What exactly are the format and semantics of this input? For > example, how exactly would this side input be used to stop the TLS > bug mentioned above? We're actually doing exactly this in TLS 1.3, but doing it in an ad-hoc way: basically using the prefix approach in some places (e.g. server CertificateVerify and client CertificateVerify in TLS 1.3 are prefixed with distinct context strings: https://tools.ietf.org/html/draft-ietf-tls-tls13-12#section-6.3.4), and switching our KDF to HKDF in others (key expansion, etc https://tools.ietf.org/html/draft-ietf-tls-tls13-12#section-7.1). > * What happens when someone wants to use more of these inputs? I'm not sure what you mean here. You mean more context labels? the goal here is one distinct context label per domain. the only purpose of the context label is domain separation. why would you want more than one? > * How should libraries handle all of the signature standards that > don't support this input? Not all signature schemes take the same set of parameters (e.g. public keys and secret keys have different structures in different messages). A library that wants to offer a generic signature scheme where the user doesn't know anything about the mechanism in use could accept a context label (byte array and length) and a message (bytearray and length). if the signature scheme supports an explicit context, it would use it. If not, it could use the concatenation approach described above. > * More to the point, how is this supposed to be better than having > the application sign a more informative message, using the > traditional concept of a signature system? "more informative" assumes that you know exactly how any bytestring is going to be interpreted in every other context. If we define a standard way that a signature or key derivation domain can distinguish itself from any other domain, then we can avoid cross-protocol attacks for every scheme that adopts this standard. Without it, each protocol will define how it thinks it should structure a message that is "informative enough" to be distinct from every other signed message in every other protocol -- but how will this be determined without cross-protocol coordination? This mechanism offers a means for cross-protocol coordination by selection of distinct context strings. (for signature schemes like Ed448 that aren't using the prefix-approach, the only requirement is context string uniqueness, since they are prefix-resistant) Does this make it seem more palatable? This isn't a strictly cryptographic property, it's a mechanism to facilitate larger cross-protocol coordination. Regards, --dkg
- [Cfrg] draft-irtf-cfrg-eddsa -- one final proposa… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Paterson, Kenny
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Salz, Rich
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Salz, Rich
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Russ Housley
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… D. J. Bernstein
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Benjamin Kaduk
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Watson Ladd
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… David Jacobson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Martin Thomson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Benjamin Kaduk
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Benjamin Kaduk
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Martin Thomson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Martin Thomson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Simon Josefsson
- [Cfrg] Side inputs to signature systems, take 2 D. J. Bernstein
- Re: [Cfrg] Side inputs to signature systems, take… Natanael
- Re: [Cfrg] Side inputs to signature systems, take… David Jacobson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] Side inputs to signature systems, take… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Watson Ladd
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Simon Josefsson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Martin Thomson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Benjamin Kaduk
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Simon Josefsson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Watson Ladd
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Martin Thomson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Martin Thomson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Bryan Ford
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Watson Ladd
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Dang, Quynh (Fed)
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… D. J. Bernstein
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Bryan Ford
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Richard Outerbridge
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… D. J. Bernstein