MAC re-definition

I am happy to see in the list of proposed changes the issue of MAC computation.

I recommend:

1) aligning ALL MAC definitions in the SSL/TLS draft to the definition
   of HMAC as appears in draft-ietf-ipsec-hmac-md5-01.txt
   which is now the *official* definition of HMAC
   (the text in this draft is identical to the one in the upcoming RFC
   on HMAC, in particular it has nothing particular about MD5, it uses
   any iterated hash function).

   Two elements of HMAC missing in the SSL definitions are:
   XOR of pads (instead of concatenation) AND
   keys PREPENDED in the inner and outer applications of the hash function.
   (The later is violated in the uses of hmac
   in draft-ietf-tls-ssl-version3-00.txt  in pages 31, 32 and 34.)

2) Even better: do not use explicitly HMAC in the MAC definitions
   that appear throughout the text of the draft.
   Instead use a notation of the form
   MAC(key, item1 + item2 +...)
   where 'key' is the key to the MAC and item1, item2, etc are the
   data items that you define in each use. The sign + is concatenation.
   Then define globally that the default MAC for SSL is HMAC as defined
   in RFC .... (in the meantime it's draft-ietf-ipsec-hmac-md5-01.txt)
   (ie, MAC(key, DataItems) is implemented by HMAC with K=key and
   text=DataItems)

   In this way the generic functionality of a MAC is highlighted, the key
   and data are clearly separated, and replaceability of HMAC if desired
   is easily achieved.

3) Some of the uses of hmac-like functions in SSL.v3 are for key generation
   rather than MAC.
   I recommend decoupling these definitions from the specific form of
   these hmac-like functions. Instead use a generic notation, for example,
   PRF (for pseudorandom function).
   The definition of key derivation would be
   PRF(key, data)[n]
   which means: compute PRF on 'data' using key 'key' and output first
   n bits.

   In this case you could define HMAC as the default PRF and sepcify
   how an arbitrary number of bits is output. This can follow the current
   SSL constructions using concatenation of
   HMAC(key, 'A', data) + HMAC(key, 'BB', data) + ...
   (a more "scalable" definition would be preferable: if you happen
    to need many bits you may need to do 'ZZZ......Z' 26 times.
    Even worst what comes after Z? :)

   An important advantage of using a generic notation like PRF is that
   it allows for pseudorandom functions based on block cipher rather
   than just keyed hash functions.
   For example, I trust more the pseudorandom properties of triple-DES
   that those of MD5. (Yes, PRF(K, data) could be defined as 3DES(K,data)).

   As for mixing MD5 and SHA I do not see any real advantage to it.
   We should consider SHA as superior anyway and then go for
   HMAC-SHA for key derivation (here the performance advantages
   of MD5 are insignificant and the probability that SHA is broken as
   a pseudorandom function but MD5 is not seems to be very very low).
   In my view, mixing MD5 and SHA does not achieve the best of
   both but the worst of both, namely, any one of the two to be
   broken in a relevant way will require chnaging the function.

   I also recommend against putting keys in variable locations
   (the latter is the case with the current definitions, e.g.,
   SHA('A' + master_secret...) vs SHA('BB' + master_secret...)



Yes I know that there are interoperability issues involving the change
to standard HMAC. These issues need to be resolved with the existing
mechanisms that support version forwarding, etc. But the more we wait
to make the changes the harder it will be.

Hugo

Received on Monday, 2 December 1996 17:15:41 UTC