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

[Tero Kivinen <[e-mail]>]

Johannes Merkle writes:
> > To fully support RSASSA-PSS we would need to include full
> > AlgorithmIdentifier ASN.1 including the parameters. I myself would
> > think that would be best option, as that would allow widest possible
> > use for this new method, i.e. we can support whatever PKIX does. Some
> > design team members disagreed, and we ended up with the current
> > compromize...
> 
> 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). 

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

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

> I would also advocate inclusion of parameters in the
> AlgorithmIdentifier inside Authentication Data. In most cases
> (except RSA-PSS with non-standard parameters) it is NULL, but I
> don't think, this is a problem.

Yep.

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

> > In security considerations section I have text:
> > ----------------------------------------------------------------------
> >    The hash algorithm registry does not include MD5 as supported hash
> >    algorithm, as it is not considered safe enough for signature use.
> > 
> >       XXX Need reference for MD5 considered unsafe.  XXX
> > ----------------------------------------------------------------------
> > 
> > Does anybody have good reference for MD5 especially with signatures
> > (not with HMAC).
> > 
> Wikipedia list a good reference: Xiaoyun Wang; Hongbo Yu (2005).
> "How to Break MD5 and Other Hash Functions".

Added that...

> If you are looking for standards... NIST SP 800-57 does not list MD5
> as approved but does not explicitly mention it as ineligible. An
> explicit caveat is included in ETSI TS 102 176-1 "Recently some new
> attacks against hash function MD5 succeeded, it was shown that MD5
> is not collision resistant by constructing classes of messages-pairs
> with the same hash value. Whereas the loss of collision resistance
> does not imply that a pre-image or second pre-image can easier be
> constructed, it is recommended to migrate to other hash functions,
> if the collision resistance becomes weaker." However, this standard
> is is from 2005 and focuses on Secure Electronic Signatures. Is this
> a problem?

I think the the "How to break MD5 ..." paper is good enough. 

> > 
> > In the security considerations section I also have:
> > ----------------------------------------------------------------------
> >    The current IKEv2 uses RSASSA-PKCS1-v1_5, and does not allow using
> >    newer padding methods like RSASSA-PSS.  This new method allows using
> >    other padding methods.
> > 
> >       XXX Need reference for RSASSA-PSS vs RSASSA-PKCS1-v1_5 security.
> >       XXX
> > ----------------------------------------------------------------------
> > 
> > RFC4055 says
> > 
> > "   The RSASSA-PSS signature algorithm is preferred over the PKCS #1
> >    Version 1.5 signature algorithm.  Although no attacks are known
> >    against PKCS #1 Version 1.5 signature algorithm, in the interest of
> >    increased robustness, RSASSA-PSS signature algorithm is recommended
> >    for eventual adoption, especially by new applications."
> > 
> > Is this still the case, or do we have some reference which would point
> > out why RSASSA-PSS is better.... Of course if we cannot support
> > RSASSA-PSS with the this new method properly, this text in the
> > security considerations section might not be needed...
> > 
> 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.

Anyway I added that reference as it points out reasons why RSASSA-PSS
might be needed...

> > 
> > In the security considerations section:
> > ----------------------------------------------------------------------
> >       XXX The text about the guidance how to select suitable hash
> >       functions is missing here.  XXX
> > ----------------------------------------------------------------------
> > 
> > I.e we need to guidance or references to good guidance. As this draft
> > is no longer only ECDSA, the RFC5480 might not be enough. For RSA, or
> > normal DSA might also need some guidance. What kind of guidance do we
> > want here.
> > 
> 
> NIST SP 800-57, Tables 2 in combination with Table 3. It seems that
> RFC 4055 also point to an early draft of NIST SP 800-57. 

Added following text:

   The "Recommendations for Key Management" ([NIST800-57]) table 2
   combined with table 3 gives recommendations for how to select
   suitable hash functions for the signature.
-- 
[e-mail]