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

[David Schinazi <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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] <mailto:[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] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>