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

[Daniel Migault <[e-mail]>]

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 <[e-mail]> 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...
> --
> [e-mail]
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>