Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519
Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 09 May 2016 07:09 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 08FA412D0A6; Mon, 9 May 2016 00:09:56 -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 tuKhcEPny1cX; Mon, 9 May 2016 00:09:53 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id D22E012B05E; Mon, 9 May 2016 00:09:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id AA94F31A5; Mon, 9 May 2016 10:09:50 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id oNPdlTN-prMK; Mon, 9 May 2016 10:09:50 +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-smtp2.welho.com (Postfix) with ESMTPSA id 36B42286; Mon, 9 May 2016 10:09:50 +0300 (EEST)
Date: Mon, 09 May 2016 10:09:48 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20160509070948.GA5360@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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABkgnnVDDoh1t-GA54b31X9GVGTyFHtjNjEhzMaGdCHkFNNO6g@mail.gmail.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/AwEHno3lZpVJBNmZf4CDgPMvxd4>
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 07:09:56 -0000
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!). 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 then the protocol itself needs to be self-consistent. But that is needed anyway (and is harder requirement than one might think). Here's one abstract API model of signature scheme with contexts: keygen: () -> (privkey, pubkey) sign: (privkey, context<0..255>, message<0..>) -> signature verify: (pubkey, context<0..255>, message<0..>, signature) -> boolean With correctness (it verifies its own signatures) and unforgeability (can't compute signatures for (context,message) one hasn't seen without private key). The algorithms can be random. > 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. 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. > 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. -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