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

On Sat, Apr 23, 2016 at 12:54 PM, Daniel Kahn Gillmor
<dkg@fifthhorseman.net> wrote:
> 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.
>
> 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
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.