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

[Yoav Nir <[e-mail]>]

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 <[e-mail]> 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
> 
>    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.

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.

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

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.