Hi Tero,
the fact that we need to study the protocol details and go into the
ASN.1 bits to ascertain that we have a problem, strongly suggests to me
that non-EC DSA is not terribly important. So if we can have a *simple*
solution that also deals with this problem, fine. Otherwise, let's just
focus on ECDSA.
Thanks,
Yaron
On 07/26/2012 04:21 PM, Tero Kivinen wrote:
Dan Harkins writes:
Well FIPS 186-3 specifically refers to SP 800-57 for "information about
the selection of the appropriate (L,N) pair in accordance with a desired
security strength for a given time period for the generation of digital
signatures." And SP 800-57 says that, for example, to produce a
signature valid "beyond 2030" it requires a minimum of 128 bits of
strength (table 4) and that when performing digital signatures of 128
bits of security the valid hash functions are SHA-256, SHA-384, and
SHA-512. You want to restrict such signatures to SHA-256 so it's
not really meeting the requirements of FIPS 186-3.
Few questions (I do not know enough about FIPS 186-3 or SP 800-57 etc
to know the answer myself).
When we have DSS signature in FIPS 186-3 format, I have understood
that there is no indication about whether the signature is ECDSA or
normal DSA, or what is the domain parameters for the ECDSA, and what
is the hash function used when generating the signature.
I.e. the signature just consist of some raw bits, and there is no
other information around it and all that other information must be
carried to the verifier over some other medium?
Is this correct?
If that is correct how does the PKIX solve this? I.e. when I have
certificate signed by the some other certificate using DSA? If my
reading of RFC5280 is correct there is this signatureAlgorithm ASN.1
blob in front of the signature itself and that gives all that
information (including the domain parameters and hash functions etc).
Is my understanding correct?
If so then I think we should use similar method in the IKEv2 too, and
fix both ECDSA and normal DSA at the same time, i.e. create one new
authentication method where the actual signature format that contains
both the signatureAlgorithm and signatureValue (4.1.1.2 and 4.1.1.3
from the RFC5280).
This will fix the problem for all DSA methods (EC or normal) and
allows using any hash function allowed by signers policy. It also
allows responder to immediately know the domain parameters and hash
function even when certificate of the public key was not delivered
inband of the IKEv2.
If we define one new authentication method then we can also deprecate
old DSA methods (DSS Digital Signature - 3, ECDSA with * on the P-*
curve - 9-11), and recommend that new implementations will use this
new method. Or we can still say that for SHA-1 DSS and SHA-2 with
those curves still use the old methods.
This same method could also be used for RSA, but as this problem of
not knowing hash-function / parameters do not exists in RSA there is
no point of changing the current RSA method.
This would also make it so that we could use any public key method the
PKIX decideds to define in the future without any changes to the IKEv2
document.
If only this protocol was designed better....
True, we can only blame ourselves. This same problem was already there
for IKEv1, but nobody noticed that we should fix this when we were
defining IKEv2.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
