Re: linting draft-ietf-msgtrk-protocol-00.txt

Paul,

I agree with your suggestion.
To reinforce your quote from Steve Bellovin about MD5,
I've been following the S/MIME WG and they have decided
to move away from MD5 and mandated SHA-1 in the latest
version of the S/MIME specs. Here's a quote from
RFC 2633 on S/MIME v3 specs:

"2.1 DigestAlgorithmIdentifier

   Sending and receiving agents MUST support SHA-1 [SHA1].  Receiving
   agents SHOULD support MD5 [MD5] for the purpose of providing backward
   compatibility with MD5-digested S/MIME v2 SignedData objects."

Since we are at the beginning of the development cycle, it would make
sense
for us to adopt the most current digest algos and not have to worry
about
backwards compatibility. Thanks.

Shiraz

[email protected] wrote:
> 
> With regard to the security of the hashing - Steve Bellovin has written -
> in draft-ietf-iab-secmech-01.txt (which has long since expired)
> 
> "5.2. HMAC
> 
>    HMAC [RFC2104] is the preferred shared-secret authentication
>    technique.  If both sides know the same secret key, HMAC can be used
>    to authenticate any arbitrary message.  This specifically includes
>    random challenges, which means that HMAC is suitable for logins.
> 
>    The disadvantage, of course, is that the secret must be known in the
>    clear by both parties.  In many situations, this is undesirable.
> 
>    When suitable, HMAC should be used in preference to older techniques,
>    notably keyed hash functions.  Keyed hashes based on MD5 [RFC1321]
>    are especially to be avoided, given the hints of weakness in MD5."
> 
> Are we sure that the proposal in draft-ietf-msgtrk-protocol-00.txt isn't
> ignoring this advice ?
> 
> Cheers,
> Paul
> --
> Paul Ford-Hutchinson : EMEA eCommerce application security :
> [email protected]
> MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5YR +44 (0)1926 462005
> 
> Lyndon Nerenberg <[email protected]> on 26/07/2000 21:08:40
> 
> Please respond to Lyndon Nerenberg <[email protected]>
> 
> To:   [email protected]
> cc:    (bcc: Paul V Ford-Hutchinson/UK/IBM)
> Subject:  linting draft-ietf-msgtrk-protocol-00.txt
> 
> Here are a few things that popped out during my initial read of the
> draft.
> 
> Section 3:
> 
> * line 2: s/message may issue the EHLO command/message MUST issue the
> EHLO command/
> 
> Section 4.2.1
> 
> s/the Tracking ID is REQUIRED to be/the Tracking ID MUST be/
> 
>   "generational counter MUST be incremented by one."
> 
> contradicts the followon sentence. Suggest: "generational counter MUST
> be incremented." and drop the following sentence (... small amount ...)
> (or provide a rational for it?).
> 
> Section 4.2.2
> 
>   s/This secret value MAY be a per-message secret/This secret value
> SHOULD
>   be a per-message secret/
> 
> Is there a reason for MAY here instead of SHOULD?
> 
> Section 4.2.4
> 
>   "This value is then expressed as a series of
>   32 hexadecimal digits, either lower- or upper-case, transmitted in
>   internet byte order (low-endian ???? )"
> 
> This should read 'case independent'.
> 
> "internet byte order" reads as if it applies to the US-ASCII string.
> This needs clarification that the ordering is of the underlying 16 byte
> binary string.
> 
> Section 6.1
> 
> s/S: 25o <[email protected]>/S: 250 <[email protected]>/
> 
> Section 7
> 
> There *are* security issues with the hash calculations, and with the
> requirements of section 4.2.2. We should at least draw attention to
> the hazards of reusing the secret.
> 
> --lyndon