Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH

From: Michael Zolotarev <[email-masked]>
Date: Tue, 20 Jun 2000 13:21:12 +1000

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:[email-masked]]
> Sent: Tuesday, June 20, 2000 1:00 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt
> 
> 
> >>>>> "Joerg" == Joerg Seidel <[email-masked]> 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
>

---

From: Paul Koning <[email-masked]>
Date: Tue, 20 Jun 2000 11:04:42 -0400 (EDT)

>>>>> "Michael" == Michael Zolotarev <[email-masked]> 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