Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519
"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Wed, 20 April 2016 08:44 UTC
Return-Path: <Kenny.Paterson@rhul.ac.uk>
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 0D70F12DD78; Wed, 20 Apr 2016 01:44:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com
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 Jd4aar5ILtU5; Wed, 20 Apr 2016 01:44:07 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0682.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::682]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E680212D7BA; Wed, 20 Apr 2016 01:44:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=g7lR2BVhr1ROcXY6xAEq4nBjDSm5FxXwdhmG/YVK95A=; b=ATAFBc8kkaelk4mkFlvbz08gP629lPcaMEvlWCAFasD11+Avolm9XeU4icndntIqXizZKcBg7kkoh5jH+odlo+7KVeEAaMMIUmEFcvwZ5fSyhWkjQ1jexPFVuPqccDkz/PXAIL/frVA9TgkTxCmaHvzEIDSeN4p3ylUBPiCJKoU=
Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1824.eurprd03.prod.outlook.com (10.166.42.150) with Microsoft SMTP Server (TLS) id 15.1.466.19; Wed, 20 Apr 2016 08:43:50 +0000
Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0466.022; Wed, 20 Apr 2016 08:43:50 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, "cfrg@ietf.org" <cfrg@ietf.org>, "draft-irtf-cfrg-eddsa.all@ietf.org" <draft-irtf-cfrg-eddsa.all@ietf.org>
Thread-Topic: draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519
Thread-Index: AQHRms27mjB4fMkE2EOrRhA6598tIZ+SnOqA
Date: Wed, 20 Apr 2016 08:43:50 +0000
Message-ID: <D33CFF00.6A70D%kenny.paterson@rhul.ac.uk>
References: <87bn543id1.fsf@alice.fifthhorseman.net>
In-Reply-To: <87bn543id1.fsf@alice.fifthhorseman.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.2.160219
authentication-results: fifthhorseman.net; dkim=none (message not signed) header.d=none;fifthhorseman.net; dmarc=none action=none header.from=rhul.ac.uk;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [92.4.66.92]
x-ms-office365-filtering-correlation-id: bf883e4b-55f4-493d-4d8b-08d368f7e571
x-microsoft-exchange-diagnostics: 1; VI1PR03MB1824; 5:44bzpYqbkFIhfOphJBz4+8B0Wq1J2n+6AY9vfPDk23zr0Zerzh4NT8tUr4lCyhHF6ZhSxFFpsXS69bf4OD8O9UI2Bd7eeKbzRNszZO6DG4k3vauOWjhIzJG8orPtgSQfiyOse4C02HHzUk7YvHoifilprpjH1dawoG8+/Ye2CVUuwL/2WfWy3oRl2PrNo9tf; 24:HE0RL4xeXHTEcb/Y/5Y9qI6AIV7R6bI6b2c9JcQTt1udzfDuyNSS2phLe/8r3wmKyhGqu2AlMjjp9AbDFFFbJXjVLed//qCCEoTJRiv/sa0=; 7:KO4aQZE+9VIQI66q/+KLTt9LYGppDpShcvjNIzSFIAshF23SEqDXP/BPaI4iKeuQBtQTNxY04tBnykbdYnZOqGhwj1jW4kRAYW5hAVEwNnZYmdj63w1hgkXuakxrj2s9Aioo1th8kI6euSm59C3uFxZdya7DrQj/PziRfbYpy61ojIQsBOc4SB5Wn5tTTZvi0rbgawrxDdR9p6S6VspjQQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1824;
x-microsoft-antispam-prvs: <VI1PR03MB182473EC213CFDA27B3766F1BC6D0@VI1PR03MB1824.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR03MB1824; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1824;
x-forefront-prvs: 0918748D70
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(53754006)(5004730100002)(122556002)(66066001)(5008740100001)(4326007)(11100500001)(5001770100001)(92566002)(4001350100001)(3280700002)(10400500002)(586003)(102836003)(1096002)(3846002)(6116002)(189998001)(81166005)(74482002)(77096005)(1220700001)(2950100001)(15975445007)(2900100001)(3660700001)(87936001)(54356999)(2906002)(76176999)(50986999)(19580405001)(106116001)(19580395003)(86362001)(2201001)(36756003)(5002640100001)(83506001)(230783001)(561944003)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1824; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-ID: <75D9269B442AF543816A808758C2B13E@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2016 08:43:50.4053 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1824
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/K3zkB-FUrH_Up70m9Sezx5PREOE>
Cc: Ondřej Surý <ondrej@sury.org>, Robert Edmonds <edmonds@debian.org>, Benjamin Kaduk <bkaduk@akamai.com>, Martin Thomson <martin.thomson@gmail.com>
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 08:44:10 -0000
Hi Daniel, Your proposal seems to me to be a very sensible idea. We are quite keen to get draft-irtf-cfrg-eddsa "shipped", as it's needed elsewhere in IETF and dependencies are building up. So, @all, let's try to have a quick discussion on the proposal and see if any reasons emerge for not adopting it. Cheers, Kenny On 20/04/2016 07:27, "Daniel Kahn Gillmor" <dkg@fifthhorseman.net> wrote: >Hi all-- > >in draft-irtf-cfrg-eddsa-05, there is a context label defined for ed448, >but no such label is defined for ed25519. (the "context label" is a way >to provide domain separation between signatures made in different >contexts, avoiding cross-protocol attacks) > >people seem OK with domain separation for ed448, but we've rejected it >for ed25519 to achieve backward compatibility with existing signatures, >and to avoid API changes to existing ed25519 libraries, as discussed in >threads like [0]. > >I wanted to float one final middle-ground proposal that would allow us >to align the APIs between the two by adding an optional context >parameter to ed25519/ed25519ph. If this isn't acceptable, please >consider instead the proposed additional Security Considerations toward >the end of this message. > >The proposal for including optional context labels in 25519 is simple: > > * in Table 1: Parameters of Ed25519, change H(x) from "SHA-512(x)" to > "SHA-512(context || x)", and change PH(x) to "context || x". > > * change the sentence describing the ph variant that follows the table > to: > > Ed25519ph is the same but with PH being SHA-512(context || x) > instead, i.e., the input is hashed using SHA-512 before signing with > Ed25519. > >If "context" is unspecified by the user it is treated as the empty >string and, the result is exactly the same as the current description. >This is also easy for someone to implement with existing ed25519 >libraries with no API change: just concatenate before signing or >verifying. > >This would mean that a signature with a context label for 25519 is not >separated from a signature *without* a context label (a weaker domain >separation than we're offering in ed448), but it at least provides a >standard way for protocols that want to make domain-separated signatures >to do so, which might help us to encourage domain separation in >standards which contemplate the use of either Ed448 or Ed25519 (their >abstract APIs are alignable). > > >I also think we need some text explaining the difference between the two >approaches. If we adopt the above proposal, we could add something like >this to the Security Considerations or section 10.3 ("Use of contexts"): > >---------- > Note that the domain separation for Ed25519 and Ed25519ph is weaker > than the domain separation for Ed448 and Ed448ph in two ways: > > (a) Signatures that do not use context labels can potentially > collide with signatures that use context labels. This can only be > mitigated by never using the same key in multiple domains without > having a domain-specific context label for each use. > > (b) Signature domains that use context labels where one context > label is a prefix of the other may also have collisions. This can be > mitigated by always choosing a context labels that consist of > printable ASCII characters followed by a single zero-valued octet. > > This weaker domain separation is accepted in Ed25519 due to widespread > existing context-free deployment and the desire to avoid breaking > backward compatibility. For Ed448, which is not yet as widely > deployed, the dom() function's stronger domain separation guarantees > are preferred. >---------- > >If we do not adopt the above changes, and leave ed25519 and ed25519ph >without any attempt at domain separation, we also probably need a bit of >text explaining why one primitive has domain separation and the other >does not, probably in either Security Considerations or section 10.3. >Otherwise, future people reading the draft would need to track down >messages like those in [0] to understand the asymmetry. > >A proposal for text in this scenario: > >----------- > Note that only Ed448 offers strong domain separation via context > labels, while Ed25519 lacks this capability. This is due to a desire > to retain backward compatibility with existing Ed25519 deployments, > and to leave the Ed25519 API as simple as possible. > > If an application or protocol needs domain separation in situations > where Ed25519 may be used, a weaker form of domain separation may be > had by prepending a context label (fixed octet string) to the message > before signing or verifying, using a different context label for each > signature domain. For the prehash variant, prepend the context to the > message before pre-hashing. > > To avoid collisions between domains when using this weaker form of > domain separation, context labels should consist of only printable > ASCII characters followed by a single-valued octet. >----------- > >What do folks think? > > --dkg > > >[0] see for example Ilari's response here to Bryan Ford at Message-Id: > 20151211202214.GA5522@LK-Perkele-V2.elisa-laajakaista.fi > https://www.ietf.org/mail-archive/web/cfrg/current/msg07713.html > > and the "On the differences of Ed25519/448 and how it affects a vote > on twoshakes-d" thread starting at Message-Id: > CAA4PzX18bcS_awPg-YDAoo90537Ot=s_nf7k_Vt75OVSdvtDrQ@mail.gmail.com > https://www.ietf.org/mail-archive/web/cfrg/current/msg07665.html
- [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