Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-signature-auth-00.txt

[Tero Kivinen <[e-mail]>]

Johannes Merkle writes:
> >> If RSA-PSS keys are used then this should not be an issue. In this
> >> case the SPKI of the cert specifies the parameters to be used.
> > 
> > Even in that case we need to say in this draft that the RSASSA-PSS
> > parameters are taken from the SPKI of the cert. If the SPKI includes
> > parameters, are those the only parameters that can be used with the
> > cert, i.e. does that mean that you cannot use any other hash than what
> > is speficied there (I am not familiar enough with RSASSA-PSS to know
> > how it works). 
> 
> Yes, restriction to the specified parameters is exactly the
> semantics of the parameter field of the SPKI. Section 1.2 of 
> RFC 4055 states:
>    When a certificate conveys an RSA public key with the id-RSASSA-PSS
>    object identifier, the certificate user MUST only use the certified
>    RSA public key for RSASSA-PSS operations, and, if RSASSA-PSS-params
>    is present, the certificate user MUST perform those operations using
>    the one-way hash function, mask generation function, and trailer
>    field identified in the subject public key algorithm identifier
>    parameters within the certificate.

Ok, I should add pointer to that in my draft.

What happens if the RSASSA-PSS-params is NOT present? Do we use
defaults, or is the certificate user allowed to pick any hash/mask etc
he feels like? If it can use any hash, then we still have problem as
the receipient cannot know which hash the other end picked.

Added following text to my draft:

----------------------------------------------------------------------
    Note, that if the RSASSA-PSS is used, and if the public key is
    specified with id-RSASSA-PSS and there is RSASSA-PSS-params, then
    those params needs to be used as specified in the Section 1.2 of
    the RFC4055 ([RFC4055]).
----------------------------------------------------------------------

> > I do not think this is going to be problem in general case. The IPsec
> > configuration usually have quite a lot of all kind of configuration /
> > policy information in both ends and some of those needs to match.
> > 
> 
> Agreed. Still it could be useful to hint to this potential issue.

Yep. And I also want to add similar text to my raw public key draft,
pointing out that if it is used to send RSASSA-PSS keys inside the
SPKI of the raw key, then you still need to follow the RFC4055, even
when the SPKI is not inside the Certificate payload.

> >> - When verifying a RSA-PSS signature based on a certificate
> >> specifying rsaEncryption in SPKI, additional information on the
> >> parameters used are needed.
> > 
> > But the problem is when you do know from the configuration that other
> > end do support RSASSA-PSS, and you can see the supported hash
> > functions from the SIGNATURE_HASH_ALGORITHMs, but you do not know
> > which hash function the other end uses, as the RSASSA-PSS oid does not
> > include it... I think that is much bigger problem. 
> > 
> This is just part of the problem I referred to: The hash function
> used as message digest is part of the parameters. The parameters
> consist of 4 parts, for many of which recommendations exist in RFC
> 4055:
> 
> 1. HashAlgorithm is the hash function used for computing the message
> digest. In contrast to PKCS#v1.5 the hash function is applied twice,
> first only to the message, the to the resulting hash concatenated
> with a fixed padding and a salt.
>
> 2. maskGenAlgorithm is the mask generating function for computing
> the padding. RFC 4055 only support the MFG-1 construction based on
> SHA-1 or SHA-2. RFC 4055 strongly recommends that the underlying
> hash function of MFG-1 be the same as the one identified by
> hashAlgorithm. I.e., when following this recommendation, the
> maskGenAlgorithm is uniquely defined by HashAlgorithm.
>
> 3. saltLength. Although RFC 4055 specifies a default length of 20
> octets, it recommends that saltLength is the number of octets in the
> hash value. I.e., when following this recommendation, the saltLength
> is uniquely defined by HashAlgorithm.
>
> 4. trailerField. RFC 4055 requires it to be 0xBC. So, there is also
> no choice left.

And in future there might be update to the RFC 4055, which adds new
hash functions to it... 

> Thus, when following the recommendations of RFC 4055, there are only
> 5 parameter sets left: 
> Set1: (SHA-1, mgf1SHA1Identifier, 20, 0xBC)
> Set2: (SHA-224, mgf1SHA224Identifier, 28, 0xBC)
> Set3: (SHA-256, mgf1SHA256Identifier, 32, 0xBC)
> Set4: (SHA-384, mgf1SHA384Identifier, 48, 0xBC)
> Set5: (SHA-512, mgf1SHA512Identifier, 64, 0xBC)
>
> I really wonder, why RFC 4055 has not defined simple OIDs for these
> 5 parameter combinations. This would make implementations limited to
> RFC 4055 recommended parameters much easier. And I really see no
> need to deviate from these recommendations. If we limit IKEv2
> authentication with RSASSA-PSS to these sets, we could specify the
> missing OIDs and forget about the parameter field. Or we could ask
> the pkix WG if they are willing to issue an RFC defining these 5
> OIDs for simplified use?

Or we can simply add the whole AlgorithmIdentifier sequence, which
would include the OID and parameters in front the signature, and that
will also take care of the problem. 

> > So do you have any RFC that we can point to which specifies the hash
> > truncation? If there ever has been two ways of doing things, I would
> > like to point to some place where it is clear which way is used here,
> > even when the other way has already been deprecated.
> > 
> 
> I just looked it up in RFC 6090 and detected that there the hash
> value is _not truncated_, which is one more reason to clarify this
> in our draft. There is no RFC defining the ECDSA algorithm and most
> RFCs refer to ANSI X9.62. So this is the proper reference.

Ok, added:

----------------------------------------------------------------------
			For the hash truncation the method of
      X9.62 ([X9.62]) MUST be used.
...
   [X9.62]    American National Standards Institute, "Public Key
              Cryptography for the Financial Services Industry: The
              Elliptic Curve Digital Signature Algorithm (ECDSA)",
              ANSI X9.62, November 2005.
----------------------------------------------------------------------

> >> There are attacks against implementations not checking for garbage
> >> after the hash value when using public exponent e=3 (a very special
> >> case, but the best attack I know of).
> >> http://csrc.nist.gov/groups/ST/toolkit/documents/dss/RSAstatement_10-12-06.pdf
> >> As permanent reference, this one is better: Ulrich Kuehn, Andrei
> >> Pyshkin, Erik Tews, Ralf-Philipp Weinmann: Variants of
> >> Bleichenbacher's Low-Exponent Attack on PKCS#1 RSA Signatures.
> >> Proceedings of Sicherheit 2008, pp. 97-109.
> > 
> > This just points the problems in the PKCS#1 RSA signatures, but does
> > not mention anything about RSASSA-PSS.
> 
> The reason why RSASSA-PSS is considered better is because there is a
> security proof (w.r.t adaptive chosen-message attacks) in the random
> oracle model. A good reference for a fair comparison with the
> conclusion that RSASSA-PSS is preferable is Alfred Menezes.
> Evaluation of Security Level of Cryptography: RSA-OAEP, RSA-PSS, RSA
> Signature. Technical Report, University of Waterloo, 2001 However,
> this paper is quite old and does not consider the latest attacks
> against the old padding method.

Added that

----------------------------------------------------------------------
   The current IKEv2 uses RSASSA-PKCS1-v1_5, which do have some problems
   ([KA08], [ME01]) and does not allow using newer padding methods like
   RSASSA-PSS.  This new method allows using other padding methods.
...
   [KA08]     Kuehn, U., Pyshkin, A., Tews, E., and R. Weinmann,
              "Variants of Bleichenbacher's Low-Exponent Attack on
              PKCS#1 RSA Signatures", Proc. Sicherheit 2008 pp.97-109.

   [ME01]     Menezes, A., "Evaluation of Security Level of
              Cryptography: RSA-OAEP, RSA-PSS, RSA Signature",
              December 2001.
-- 
[e-mail]