Re: [Cfrg] I-D Action: draft-irtf-cfrg-eddsa-08.txt

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Cfrg [mailto:[e-mail]] On Behalf Of Yoav Nir
> Sent: Thursday, August 25, 2016 2:07 PM
> To: <[e-mail]> <[e-mail]>
> Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-eddsa-08.txt
> 
> Hi.
> 
> I’ve read this draft in the context of writing both RFC4492bis for TLS and draft-
> nir-ipsecme-eddsa for IPsecME. So of course I’m mainly interested in selecting
> the right variant for each key length. I’ll get back to that, bit first some things
> that I found that I don’t think are clear enough:
> 
> Section 10.3 begins like this:
>    Contexts can be used to separate uses of the protocol between
>    different protocols (which is very hard to reliably do otherwise)
> 
> So I think you meant to separate uses of the *algorithm* between different
> protocols.
> 
> The section proceeds to give some warnings about using contexts. The first
> paragraph requires not to use parts of the message for the context, but prohibits
> this with a SHOULD NOT. No explanation is given as to why not, nor in what
> cases you would do so anyway (it is a SHOULD NOT rather than a MUST NOT).
> The third paragraph is about percolating the context string through APIs which
> currently do not have context parameters. That is pretty clear although I don’t
> like the re-use of the word “protocol” at the very end. I think API is more
> correct.
> 
> The second paragraph, I don’t understand:
>       Contexts SHOULD NOT be used oppurtunistically, as that kind of use
>       is very error-prone.  If contexts are used, one SHOULD require all
>       signature schemes avaiable for use in that purpose support
>       contexts.
> 
> What does that even mean? AFAIK EdDSA is the only scheme with contexts. So if
> I plan to use EdDSA with context I SHOULD use contexts in, say, RSA? That can’t
> work, so should I use contexts only when EdDSA is the only defined signature
> algorithm for the protocol? I don’t think that’s what was meant.

The reading that I have from the text and which is enforced from other messages from Ilari is that he is saying don't use a context string unless all of the signature algorithms allow for the use of context strings.  So I believe that is exactly what is meant.

> 
> Section 10.5 explains well the considerations for choosing between 25519 and
> 448. It also makes the case for not using the pre-hashed version if it can be
> avoided. Then there’s this text about contexts:
>    Ed25519ctx and Ed448 have contexts.  However, this is balanced by the
>    problems noted in section about contexts.
>    On implementation front, Ed25519 is widely implemented, and has many
>    high-quality implementations.  The others have much worse support.
> 
> I’m assuming that “section about contexts” is 10.3. Might be worth to clarify
> that with a reference. And I’m guessing the problems noted are the ones in that
> second paragraph, although I still don’t understand why it is error-prone.
> 
> 
> So with all that in mind, which variants should I choose for TLS and IKE?
> Obviously the pre-hashed variants are out, as there is a SHOULD NOT against
> their use and neither TLS nor IKE sign any prohibitively large messages. These are
> not like the multi-megabyte CRLs discussed recently on the curdle list. So it
> comes down to contexts. Do I define some context strings like “IKEv2 Initiator
> Sign”, “TLS Server Sign”, etc. Or do I use the non-context (or empty context)
> versions because both protocols also support other signature schemes such as
> RSA, DSA and ECDSA?

I wonder if the SHOULD NOT on pre-hash algorithms cannot be eased with the most recent updates to the document.

At this point I am not sure that context strings are going to be useful.  In the PKIX and CMS contexts I am planning on pushing the empty string or absent context.

Jim

> 
> Thanks
> 
> Yoav
> 
> 
> > On 19 Aug 2016, at 12:53 PM, [e-mail] wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Crypto Forum of the IETF.
> >
> >        Title           : Edwards-curve Digital Signature Algorithm (EdDSA)
> >        Authors         : Simon Josefsson
> >                          Ilari Liusvaara
> > 	Filename        : draft-irtf-cfrg-eddsa-08.txt
> > 	Pages           : 59
> > 	Date            : 2016-08-19
> >
> > Abstract:
> >   The elliptic curve signature scheme Edwards-curve Digital Signature
> >   Algorithm (EdDSA) is described.  The algorithm is instantiated with
> >   recommended parameters for the edwards25519 and edwards448 curves.
> >   An example implementation and test vectors are provided.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-irtf-cfrg-eddsa/
> >
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-08
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-eddsa-08
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > Cfrg mailing list
> > [e-mail]
> > https://www.irtf.org/mailman/listinfo/cfrg
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg