[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH
Stephen,
>
> I may have lost track of the counter argument here. Why would one
> not want to have a TSA do the best possible job when it comes to
> ensuring syntactic consistency re its inputs?
A few of us are being concerned that forcing the TSA to 'know' the hash oid
and to perform the sanity check is an unnecessary requirement, causing more
evil than good.
Instead of reiterrating our position, I've attached a few messages from the
thread which summarize the views.
Regards
Michael
--- Begin Message ---
I agree as well. There is no need for the TSA to check anything about the
imprint. This requirement should be removed from the draft.
Terry Hayes
thayes@netscape.com
Michael Zolotarev wrote:
> > If I were to generate my imprint with hash algorithm FRED that has a
> > 37 byte digest, does it matter to the TSA? No, it does not. So why
> > are we saying that the TSA needs to know the OID for FRED, and the
> > associated digest length?
> >
> > The spec says that it's done to consistency-check the length of the
> > imprint. Sure, but to what end? If I send a digest generated by FRED
> > but truncate it to 31 bytes, what purpose is served by the TSA saying
> > "naughty boy you threw away 6 bytes"? I may in fact have a legitimate
> > reason for doing this -- just as IPsec has a legitimate reason for
> > throwing away some of the hash bytes in the HMAC construct. If it
> > actually mattered to the TSA algorithms, that would be one thing. But
> > since the only purpose of the check is to do the check, let's get rid
> > of it, simplify the spec, make the TSA implementations more reliable,
> > and eliminate the need to ECO the spec every time a new hash appears.
> >
> > paul
>
> I agree (expecting a public outcry here :). I always felt pretty
> uncomfortable with the TSA having to recognise the hash OID and checking
the
> length. And on top of if, this would now allow a client tp send a NO-HASH
> imprint, a clear text, if they want to.
>
> Michael
> >
--- End Message ---
--- Begin Message ---
>>>>> "Michael" == Michael Zolotarev <mzolotarev@baltimore.com> writes:
Michael> Folks, Haven't we already had a discussion about hash
Michael> algorithm for messageImprint?
Michael> I believe that the consensus was (and it is 100% reflected
Michael> in the current draft) to allow a user to use whatever digest
Michael> he/she wants. It is NOT a TSA concern if a user used 'weak'
Michael> hash. The TSA does not inspect, modify, store or analyse the
Michael> content of messageImprint - it only checks that the length
Michael> of the hash corresponds to the hash algorithm. If so, then
Michael> why should the draft imply any limitations on type of digest
Michael> algorithms, except saying that they must be known?
Michael> The position of the draft is, if I interpret it correctly:
Michael> 1) The TSA does not care about hash algorithm used in
Michael> messageImprint. But the algorithm must be known, to allow
Michael> TSA to sanity-check the length of digested data. 2) The
Michael> user is ADVICED to use strong hash, such as SHA-1 or MD5.
Michael> This position of the draft with regards to hash is general,
Michael> and provides enough space to grow, instead of being
Michael> unnecessary restrictive. Can we leave it in peace :)?
Can we remove this unnecessary restrictions instead?
A rule of thumb of protocol design is that requirements are put in
because they are necessary for interoperability. In the case we have
here, that rule of thumb doesn't apply.
If I were to generate my imprint with hash algorithm FRED that has a
37 byte digest, does it matter to the TSA? No, it does not. So why
are we saying that the TSA needs to know the OID for FRED, and the
associated digest length?
The spec says that it's done to consistency-check the length of the
imprint. Sure, but to what end? If I send a digest generated by FRED
but truncate it to 31 bytes, what purpose is served by the TSA saying
"naughty boy you threw away 6 bytes"? I may in fact have a legitimate
reason for doing this -- just as IPsec has a legitimate reason for
throwing away some of the hash bytes in the HMAC construct. If it
actually mattered to the TSA algorithms, that would be one thing. But
since the only purpose of the check is to do the check, let's get rid
of it, simplify the spec, make the TSA implementations more reliable,
and eliminate the need to ECO the spec every time a new hash appears.
paul
--- End Message ---
--- Begin Message ---
Folks,
Haven't we already had a discussion about hash algorithm for messageImprint?
I believe that the consensus was (and it is 100% reflected in the current
draft) to allow a user to use whatever digest he/she wants. It is NOT a TSA
concern if a user used 'weak' hash. The TSA does not inspect, modify, store
or analyse the content of messageImprint - it only checks that the length of
the hash corresponds to the hash algorithm. If so, then why should the draft
imply any limitations on type of digest algorithms, except saying that they
must be known?
The position of the draft is, if I interpret it correctly:
1) The TSA does not care about hash algorithm used in messageImprint. But
the algorithm must be known, to allow TSA to sanity-check the length of
digested data.
2) The user is ADVICED to use strong hash, such as SHA-1 or MD5.
This position of the draft with regards to hash is general, and provides
enough space to grow, instead of being unnecessary restrictive. Can we leave
it in peace :)?
Michael
> -----Original Message-----
> From: Paul Koning [mailto:pkoning@xedia.com]
> Sent: Tuesday, June 20, 2000 1:00 AM
> To: seidel@timeproof.de
> Cc: FRousseau@chrysalis-its.com; Denis.Pinkas@bull.net;
> ietf-pkix@imc.org
> Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt
>
>
> >>>>> "Joerg" == Joerg Seidel <seidel@timeproof.de> writes:
>
> Joerg> Comments inline.
> >> TSA implementations MUST support SHA-1. TSA implementations
> >> SHOULD support MD5.
>
> Joerg> I think there are good reasons not to use MD5 in time
> Joerg> stamps. They should use a strong hash function in order to
> Joerg> achive long validity periods. MD5 is likely to be unsafe (=not
> Joerg> collision free) soon and is already discuraged by german
> Joerg> authorities.
>
> Joerg> IF we add a section about algorithms, it should maybe read:
> Joerg> "TSA implementations MUST support SHA-1. TSA implementations
> Joerg> SHOULD NOT support MD5.". But I think such a section is not
> Joerg> very necessary.
>
> IANAC, but from what I understand the currently known attacks on MD5
> are nowhere near strong enough to justify that.
>
> I don't have a problem with the current text (SHA-1 required, MD5
> recommended). I do have a problem with text that implies that MD5 is
> bad, because I don't know of data that supports such an assertion.
>
> Also, it doesn't seem like a good idea for the timestamp spec to give
> very different signals from the other security specs. If there really
> is good reason to say these kinds of things about MD5, let's have them
> identified. (German authorities are not a good reason. Cryptanalysis
> that shows weaknesses of interesting size would be.) If the issues
> are real, changes to MD5 text should be applied across the board.
>
> paul
>
--- End Message ---