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

[Daniel Migault <[e-mail]>]

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

> Hi, Daniel.
>
> See my comments inline.
>
> Also see this pull request:  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.
>
>
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>