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

Paul Lambert <paul@marvell.com> Mon, 25 April 2016 18:03 UTC

Return-Path: <paul@marvell.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 583AA12D60D; Mon, 25 Apr 2016 11:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 1X4JkrW70xsx; Mon, 25 Apr 2016 11:03:22 -0700 (PDT)
Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2003C12D5C0; Mon, 25 Apr 2016 11:03:21 -0700 (PDT)
Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u3PI2LqF026754; Mon, 25 Apr 2016 11:03:13 -0700
Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0a-0016f401.pphosted.com with ESMTP id 22g6dkdsnd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 25 Apr 2016 11:03:13 -0700
Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 25 Apr 2016 11:03:12 -0700
Received: from SC-EXCH03.marvell.com ([fe80::6cb0:4dfa:f3f3:b8b6]) by SC-EXCH03.marvell.com ([fe80::6cb0:4dfa:f3f3:b8b6%21]) with mapi id 15.00.1104.000; Mon, 25 Apr 2016 11:03:12 -0700
From: Paul Lambert <paul@marvell.com>
To: Watson Ladd <watsonbladd@gmail.com>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Thread-Topic: Ed448ctx -> was RE: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519
Thread-Index: AdGfHLbxXSmvhYAVSTSYeSYC4ZCjPA==
Date: Mon, 25 Apr 2016 18:03:12 +0000
Message-ID: <5e514b7c361f4ed9a4d6ea41d40c350c@SC-EXCH03.marvell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.93.176.43]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-25_08:, , signatures=0
X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1604250291
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/ZgXOzUtsuWvHsBHPc07RTFQ8ljA>
Cc: Simon Josefsson <simon@josefsson.org>, Robert Edmonds <edmonds@debian.org>, "draft-irtf-cfrg-eddsa.all@ietf.org" <draft-irtf-cfrg-eddsa.all@ietf.org>, "cfrg@ietf.org" <cfrg@ietf.org>, =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= <ondrej@sury.org>, Benjamin Kaduk <bkaduk@akamai.com>
Subject: [Cfrg] Ed448ctx -> was RE: 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, 25 Apr 2016 18:03:23 -0000

> > On Sat 2016-04-23 03:23:15 -0400, Simon Josefsson wrote:
> >> Further, introducing this tweak late in the process appears unfortunate.
> >> We are having serious trouble shipping documents people have been
> >> waiting for as it is.  Redefining what they will get this late in the
> >> process is harmful.
> >
> > My goal in raising this is not to delay the process further, but to at
> > least clarify for future readers why the interfaces for Ed25519 and
> > Ed448 differ by a "context" argument, and to give some form of
> > implementation guidance to people who want to use that argument while
> > being able to use both signature schemes.

Making names clear is a good idea.
Perhaps Ed448 should be renamed Ed448ctx


Paul


> >
> > A recent example is
> > https://tools.ietf.org/html/draft-ietf-curdle-dnskey-eddsa-00, which
> > defines DNSKEY records for both Ed25519 and Ed448.  I spoke to the
> > authors about using a context label to avoid RRSIGs from being re-usable
> > in non-RRSIG contexts.
> >
> > Section 4 there now says:
> >
> >   [...]
> >    EdDSA signatures in this scheme use the 17-octet context label
> >    'DNSSEC SIGNATURE\0' (where \0 represents a zero-valued octet).
> >
> >    (Note: Only Ed448 has the Context specified.  Before publishing the
> >    final draft we need to specify what to do with Ed25519 Context.)
> >
> >
> >> So here is a suggestion.  Write a document describing a Ed25519-variant
> >> called Ed25519ctx.  I would help work on it.  For those implementations
> >> that are interested in using Ed25519ctx (which are they?), try to get
> >> them aligned behind the document.  If there are, say, two different
> >> protocols that have a desire to use contexts, I would believe that there
> >> shouldn't be a problem getting the document published as an RFC.
> >
> > This will only further delay systems that want to use Ed25519; or it
> > will discourage people from even trying to distinguish between domains
> > that do use Ed25519 ("don't bother, unless you use Ed25519ctx instead").
> >
> > As i wrote in my mail that started this thread, i'd be fine with just
> > the addition to the security considerations explaining the distinction
> > between the primitives, if that would get the draft out the door more
> > promptly.  I don't want this to drag on any longer than anyone else
> > does.
> 
> Systems actually deployed today are actually using signature systems
> that don't have the context argument. The whole argument that we need
> to reconsider what signatures are is fine: but it shouldn't stop us
> from introducing a new signature scheme that meets the standard
> definition.
> 
> >
> >            --dkg
> >