Re: [IPsec] draft-ietf-ipsecme-eddsa-01 pre-hash SHOULD NOT or MUST NOT

[Yoav Nir <[e-mail]>]

> On 5 Apr 2017, at 16:26, Tero Kivinen <[e-mail]> wrote:
> 
> Now the pre-hash algorithms are SHOULD NOT:
> 
>   The pre-hashed versions of Ed25519 and Ed448 (Ed25519ph and Ed448ph
>   respectively) SHOULD NOT be used in IKE.
> 
> I think we could say MUST NOT be used.

As it turns out they cannot be used, because the latest CURDLE draft removed the definitions of OIDs for the pre-hashed versions.  Still, I’m not comfortable proscribing one algorithm in a document about a different (although related) algorithm. How about:

OLD:
   The pre-hashed versions of Ed25519 and Ed448 (Ed25519ph and Ed448ph
   respectively) SHOULD NOT be used in IKE.

NEW:
   This document describes the use of the non pre-hashed versions of
   Ed25519 and Ed448 only.

> I.e, say that pre-hash versions MUST NOT be used, and that Ed25519 and
> Ed448 MUST be used with "Identity" hash identifier, and none of the
> other currently defined signature algorithms MUST NOT use "Identity"
> hash..

OLD:
   Ed25519 and Ed448 are only defined with the Identity hash, and MUST
   NOT be sent to a receiver that has not indicated support for the
   "Identity" hash.

NEW:
   Ed25519 and Ed448 are only defined with the Identity hash, and MUST
   NOT be sent to a receiver that has not indicated support for the
   "Identity" hash. No other signature algorithm is currently defined
   that should use the Identity hash, so this hash MUST NOT be used
   with any current algorithm.

> The following part of the security considerations might also need
> updating:
> 
> 	       On the other hand there is
>   no good reason to pre-hash the inputs where the signature algorithm
>   either does not require it or performs a hash internally.
> 
> This sentence would indicate that if the RSA key is large enough so we
> can actually sign the full data without pre-hashing, that would be
> something we would prefer. I do not think we actually want to allow
> that. We should say that Identity hash identifier MUST only be used
> when using signature algorithms specifically supporting it.
> 
>   	       	   	      	 	    For this
>   reason implementations SHOULD have the "Identity" value in the
>   SIGNATURE_HASH_ALGORITHMS notification when they support EdDSA.
>   Implementations SHOULD NOT have other hash algorithms in the
>   notification if all signature algorithms have this property.
> 
> If implementation supports EdDSA then it is policy decision whether it
> wants to use it, and wheter it wants ot include "Identity" as one of
> the hash algorithms.

How about:

3.  Security Considerations

   The new "Identity" value is needed only for signature algorithms that
   accept an arbitrary-sized input.  It MUST NOT be used if none of the
   supported and configured algorithms have this property.  On the other
   hand there is no good reason to pre-hash the inputs where the
   signature algorithm has that property.  For this reason
   implementations MUST have the "Identity" value in the
   SIGNATURE_HASH_ALGORITHMS notification when EdDSA is supported and
   configured.  Implementations SHOULD NOT have other hash algorithms in
   the notification if all supported and configured signature algorithms
   have this property.


> --
> [e-mail]