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

From: [email-masked]
Date: Fri, 19 Aug 2016 02:53:44 -0700

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/

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 19 Aug 2016 12:56:19 +0300

> 	Filename        : draft-irtf-cfrg-eddsa-08.txt

Just a few spelling fixes.

-Ilari

---

From: Yoav Nir <[email-masked]>
Date: Fri, 26 Aug 2016 00:06:41 +0300

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.

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?

Thanks

Yoav

> On 19 Aug 2016, at 12:53 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: Jim Schaad <[email-masked]>
Date: Thu, 25 Aug 2016 15:02:15 -0700

> -----Original Message-----
> From: Cfrg [mailto:[email-masked]] On Behalf Of Yoav Nir
> Sent: Thursday, August 25, 2016 2:07 PM
> To: <[email-masked]> <[email-masked]>
> 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:
> 
> 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.
> 
> 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:
> 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

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 26 Aug 2016 08:40:05 +0300

> > So I think you meant to separate uses of the *algorithm* between

Actually, uses of the same key between different protocols (of the level
that handle signatures).

These uses are actually very difficult to separate besides labeling
the key with the protocol it is used with (which sometimes is not an
option).
 
E.g. TLS server signatures and PKIX CSRs are signed by the same RSA or
ECDSA keypairs. No separation (nor can it reasonably be added), but
fortunately those don't seem to interact in nasty ways.

However, with some pairs that might use the same keys, one is not so
lucky... But best not to mix keys between protocols unless absolutely
necressary (given the problems signatures have).

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

Right.

(Making contextualized RSA-based or ECDSA-based signature scheme is not
difficult).

> > second paragraph, although I still don’t understand why it is error-prone.

It is not error-prone. Using contexts plays hell with interfaces (which are
usually not designed to take the new input).

> recent updates to the document.

Ed25519ph is still problematic (in a different way now, an implementation
problem, not a security problem).

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

Taking interfaces into account, contexts probably are pretty much useless.

-Ilari