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

[Johannes Merkle <[e-mail]>]

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


> 
>> However, RSA-PSS keys are hardly supported yet. If the SPKI includes
>> just an rsaEncryption OID, there are several problems:
>> - A peer with an RSA signing key supporting RSA-PSS has no means to
>> determine if the other peer supports PSS as well or if he should
>> better fall back to PKCS#1v1.5. At least he can find out with trial
>> and error.
> 
> Or by configuration / policy. I.e. if the policy says RSASSA-PSS is to
> be used, then it can be assumed it also works for those peers where
> the policy requires it...
> 
> 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.

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

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?

> 
>>> ----------------------------------------------------------------------
>>> 			   For the hash truncation the method of
>>>       X9.62, SEC1 and IO 14888-3 MUST be used.  XXX Need reference for
>>>       X9.62/SEC1 etchere XXX.
>>> ----------------------------------------------------------------------
>>>
>>> I.e. the draft points to this hash truncation method. Does anybody
>>> have proper reference for that, and it might be good if we could
>>> summarize it here too, as not all people have access to those other
>>> specifications.
>>
>> I have been the one bringing up this issue, so I should comment on
>> this ;-) The issue is that ISO 15946-2 defines a different hash
>> truncation method. But actually, ISO 15946-2 is deprecated
>> (withdrawn) in favor of ISO 14888. Therefore, I don't think we need
>> to specify anything w.r.t hash truncation. It is now uniformly
>> defined in all current standards.
> 
> 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.


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



-- 
Johannes