Subject: Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00

From: Daniel Migault <[email-masked]>
Date: Wed, 8 Mar 2017 13:49:07 -0500

Hi,

Please find my comments regarding the draft. I believe the draft is ready
to be moved forward. I do not have strong opinion on the value to assign.

Yours,

Daniel

   The Internet Key Exchange protocol [RFC7296] can use arbitrary
   signature algorithms as described in [RFC7427].  The latter RFC
   defines the SIGNATURE_HASH_ALGORITHMS notification where each side of
   the IKE negotiation lists its supported hash algorithms.  This
   assumes that all signature schemes involve a hashing phase followed
   by a signature phase.  This made sense because most signature
   algorithms either cannot sign messages bigger than their key or
   truncate messages bigger than their key.

   EdDSA ([I.D-eddsa]) defines signature methods that do not require
   pre-hashing of the message.  Unlike other methods, these accept
   arbitrary-sized messages, so no pre-hashing is required.  These
   methods are called Ed25519 and Ed448, which respectively use the
   Edwards 25519 and the Edwards 448 ("Goldilocks") curves.  Although
   that document also defines pre-hashed versions of these algorithm,
   those versions are not recommended for protocols where the entire to-
   be-signed message is available at once.

MGLT: I think that a pointer for the recommendation should be provided -
section 10.5 of I.D-eddsa.

The first sentence of the paragraph above confuses me. Although this si
true, I prefer to say that  EdDSA ([I.D-eddsa]) defines signatures methods
that includes pre-hasing as well as signature methods that do not require
prehashing. Following the recommendation of Section 10.5 I.D-eddsa, the
pre-hash variant SHOULD NOT be used.

Given the title, it would be more appropriated to have the first paragraph
here.

   EdDSA defines the binary format of the signatures that should be used
   in the "Signature Value" field of the Authentication Data Format in
   section 3.  The CURDLE PKIX document ([I.D-curdle-pkix]) defines the
   object identifiers (OIDs) for these signature methods.  For
   convenience, these OIDs are repeated in Appendix A.

MGLT: Note that the pkix document is still on discussion. -- Although IOD
seems out of the scope of the discussion.

   In order to signal within IKE that no hashing needs to be done, we
   define a new value has in the SIGNATURE_HASH_ALGORITHMS notification,
   one that indicates that no hashing is performed.

On Wed, Feb 15, 2017 at 10:11 AM, Tero Kivinen <[email-masked]> wrote:

> Andreas Steffen writes:
> > I personally think that 0 would have been legitimate for the "Identity"
> > hash but the next unassigned value (5) is also ok for me.
> >
> > Could you please ask IANA for an early assignment of the code point?
> > strongSwan 5.5.2 with Ed25519 support is ready to be deployed,
> > thus we would be able to release the stable version as soon as
> > the code point has been assigned.
>
> Before we can make code point allocation, we need to agree on whether
> it is going to be zero or next number. As you can see from the emails
> in this list there is not agreement on this yet, so even if authors
> make IANA request to ask for assignment, when it comes to me (as for
> expert review) few days later, I would wait for the comments on the
> list to agree on which number we are going to allocate.
>
> Now it seems more people are supporting allocating something else than
> zero...
>
> As for the process:
>
> > > As this is expert review registry there is no need to ask for early
> > > allocation, the normal process is just to fill in the IANA general
> > > request for assignments, which then goes to the IANA and they will
> > > then send it to the expert (me) for verification.
>
> And then we will then come back to this list to finish this
> discussion...
> --
> [email-masked]
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Yoav Nir <[email-masked]>
Date: Sun, 12 Mar 2017 20:14:40 +0200

Hi, Daniel.

See my comments inline.

Also see this pull request:  https://github.com/ietf-ipsecme/drafts/pull/25 <https://github.com/ietf-ipsecme/drafts/pull/25>

Unless I hear some push-back, I will submit this right before the deadline.

Yoav

> On 8 Mar 2017, at 20:49, Daniel Migault <[email-masked]> wrote:
> 
> Hi,
> 
> Please find my comments regarding the draft. I believe the draft is ready to be moved forward. I do not have strong opinion on the value to assign.
> 
> Yours,
> 
> Daniel
> 
> MGLT: I think that a pointer for the recommendation should be provided - section 10.5 of I.D-eddsa.

Added. Except that now it’s in section 8.5 of RFC 8032.

> The first sentence of the paragraph above confuses me. Although this si true, I prefer to say that  EdDSA ([I.D-eddsa]) defines signatures methods that includes pre-hasing as well as signature methods that do not require prehashing.

Yes, but the first paragraph is all about the assumption that all signature methods have a pre-hash stage. The new thing about EdDSA is that it introduces a method that does not have a pre-hash stage. The fact that we are not even specifying the use of EdDSA with pre-hash is all the more reason to push the mention of this to the end of the paragraph.

How about:

   EdDSA ([RFC8032]) defines signature methods that do not require pre-
   hashing of the message.  Unlike other methods, these accept
   arbitrary-sized messages, so no pre-hashing is required.  These
   methods are called Ed25519 and Ed448, which respectively use the
   Edwards 25519 and the Edwards 448 ("Goldilocks") curves.  Although
   that document also defines pre-hashed versions of these algorithm,
   those versions are not recommended for protocols where the entire to-
   be-signed message is available at once.  See section 8.5 or RFC 8032
   for that recommendation.

> MGLT: Note that the pkix document is still on discussion. -- Although IOD seems out of the scope of the discussion.

Since I’m referencing an I-D normatively, they become a cluster. If Curdle decides to allocate other OIDs we’ll fix this specification as well.

Not that any of us expect that to happen.

Yoav

BTW: RFC 8032 is Informational, while this document and RFC4492bis and the Curdle I-D are standards track. So I guess the shepherd’s write-up should reflect that RFC 8032 should be added to the downref registry.

---

From: David Schinazi <[email-masked]>
Date: Sun, 12 Mar 2017 16:21:28 -0700

Yoav,

The diff looks good to me.

Based on the discussion in this thread, it looks like there is consensus
to not use 0 as the value for Identity.
Would it make sense to reflect that in the document?
The "IANA Considerations" section currently states:

IANA is requested to assign a new value from the "IKEv2 Hash
Algorithms" registry with name "Identity" and this document as
reference.  Since the value zero was reserved by RFC 7427 and this
"Identity" hash is no hash at all, assigning the value zero to
Identity seems appropriate.

Could we replace this with:

IANA is requested to assign a new value from the "IKEv2 Hash
Algorithms" registry with name "Identity" and this document as
reference. Since several current implementation already use
the value zero with a different meaning, assigning the next
available value (currently 5) seems appropriate.

Thanks,
David

> On Mar 12, 2017, at 11:14, Yoav Nir <[email-masked]> wrote:
> 
> Hi, Daniel.
> 
> See my comments inline.
> 
>> On 8 Mar 2017, at 20:49, Daniel Migault <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi, 
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 13 Mar 2017 01:32:03 +0200

Thanks, I will change that (but not put in the part about 5)

The RFC editor anyway changes this to “IANA has assigned the value 5 in the …” so it doesn’t matter much what we write.

Modified the PR

Yoav

> On 13 Mar 2017, at 1:21, David Schinazi <[email-masked]> wrote:
> 
> Yoav,
> 
>> On Mar 12, 2017, at 11:14, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi, Daniel.
>> 
>> See my comments inline.
>>

---

From: Daniel Migault <[email-masked]>
Date: Sun, 12 Mar 2017 19:53:13 -0400

Hi,

This looks good to me.

Here is the text to justify the downref ;-)
The Downref is justified by RFC3967 as it falls into the following case:
   o  A standards track document may need to refer to a protocol or
      algorithm developed by an external body but modified, adapted, or
      profiled by an IETF informational RFC.

Yours,

Daniel

On Sun, Mar 12, 2017 at 2:14 PM, Yoav Nir <[email-masked]> wrote:

> Hi, Daniel.
>
> See my comments inline.
>
> Also see this pull request:  https://github.com/ietf-
> ipsecme/drafts/pull/25
>
> prehashing.
> Yes, but the first paragraph is all about the assumption that all
> signature methods have a pre-hash stage. The new thing about EdDSA is that
> it introduces a method that does not have a pre-hash stage. The fact that
> we are not even specifying the use of EdDSA with pre-hash is all the more
> reason to push the mention of this to the end of the paragraph.
>
> How about:
>
> Since I’m referencing an I-D normatively, they become a cluster. If Curdle
> decides to allocate other OIDs we’ll fix this specification as well.
>
> BTW: RFC 8032 is Informational, while this document and RFC4492bis and the
> Curdle I-D are standards track. So I guess the shepherd’s write-up should
> reflect that RFC 8032 should be added to the downref registry.
>
>
>