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

[Paul Lambert <[e-mail]>]

> > 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
> >