Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519
Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 10 May 2016 06:29 UTC
Return-Path: <ilariliusvaara@welho.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 6CBB312D094; Mon, 9 May 2016 23:29:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 pFMfcXUSPu1q; Mon, 9 May 2016 23:29:24 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3781512B063; Mon, 9 May 2016 23:29:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 30EBB2EE9; Tue, 10 May 2016 09:29:22 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id PeEFBr99KNvX; Tue, 10 May 2016 09:29:20 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-155-121.bb.dnainternet.fi [87.100.155.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id EDC292313; Tue, 10 May 2016 09:29:20 +0300 (EEST)
Date: Tue, 10 May 2016 09:29:19 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: cfrg@ietf.org, draft-irtf-cfrg-eddsa.all@ietf.org
Message-ID: <20160510062919.GA17523@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> <CABkgnnVDDoh1t-GA54b31X9GVGTyFHtjNjEhzMaGdCHkFNNO6g@mail.gmail.com> <20160509070948.GA5360@LK-Perkele-V2.elisa-laajakaista.fi> <alpine.GSO.1.10.1605092210490.26829@multics.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <alpine.GSO.1.10.1605092210490.26829@multics.mit.edu>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/B40trrqSWpy9EIjTRWFNpcKC_Gk>
Resent-From: alias-bounces@ietf.org
Resent-To: <>
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: Tue, 10 May 2016 06:29:27 -0000
On Mon, May 09, 2016 at 11:04:20PM -0400, Benjamin Kaduk wrote: > On Mon, 9 May 2016, Ilari Liusvaara wrote: > > > On Mon, May 09, 2016 at 10:23:31AM +1000, Martin Thomson wrote: > > > 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? > > > > To actually use contexts, you need a way to do contexts all the way > > up to lowermost common layer, which might very well be the signature > > primitive itself. This impiles that all the needed contexts exist > > and can be specified via an API (existing ones don't support it!). > > I'm still not conviced that we're all talking about the same thing when we > say "context". > > The two different "context"s I've seen talked about are: > > (1) Ed448ctx-style, as an "extra signature input" that is mixed into the > signature in a way that prevents shifting content from the context input > to the data input of the signature algorithm (or vice versa). And there is a transform that obtains signature scheme with contexts from scheme without one. Obviously not needed if scheme already has contexts. > (2) "flat"-style, as in "a string that is prepended or appended to the > data to be signed" that provides only partial domain-separation but can be > bolted on to existing signature algorithms post-facto. (E.g., as in > https://github.com/unicorn-wg/context-labels) That is just broken. You can not add signature-level contexts into existing signature scheme without obtaining a new scheme. At least not reliably, which in cryptography means the same as not at all. > Clearly your statement is true for (1)-style contexts, but it seems that > for (2)-style contexts, any participant in the call chain could choose to > conver the context into part of the signature input and thereby translate > from a context-ful API to a context-free one. And looks like I got the layers wrong way around, it should have been "uppermost common layer". But basically, if you need contexts, you require them. Anything else is just too error-prone. EdDSA spec says not to use signature-level key-binding, even if it works just fine with EdDSA. The reason why is that there are many _other_ signature schemes where signature-level key-binding utterly fails. > > At the level of raw signatures, this would imply defining abstract > > API model and then having all context-capable signatures, either > > obtained by transforming non-context-capable scheme (the transform > > is too trivial to contain here) or having natively context-capable > > schemes. > > And here we get into all the complications that makes djb dislike extra > inputs to signature algorithms (and rightly so). Well, the alternatives besides just giving different keys to things that aren't known to play well together are even worse. > > Well, nothing prevents having multiple contexts at different levels, > > but all contexts involved need to be able to be specified to be > > correct. > > > > E.g. openpgp -> git-push-signature. That's not interchangeable with > > git-push-signature nor openpgp. > > prepending "git-push-signature" || 0 || "openpgp" || 0 to the data to be > signed (as in my (2) above) seems naturally composable. Well, this is about contexts at different layers (if multiple layers have contexts). Then all have to match. And if so, then it is unlikely to be implemented via such prepend. > > > 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. > > > > Also, TLS keys get reused in CSR signing, and CSRs are based upon ASN.1, > > which is let's say pretty different from TLS syntax... > > > > > I disagree with the notion of there being "serious" or "fundamental" > > > usability problems. > > > > The reason for those usability problems: APIs and what is offered. > > I agree that for (1), the API situation is a mess and there are not any > currently usable library APIs. And thus contexts are currently unusable, as such APIs are prerequisite for usage of contexts. > My question is, what are the downsides of (2)? It can perhaps offer a > false sense of security to protocol designers and/or implementors that > ought to be using separate keys, but if we spin it as something to be used > in addition to key separation, maybe it's not so bad. Are there other > disadvantages of (2)? That kind of construction is just a minefield. -Ilari
- [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