- From: <HUGO@watson.ibm.com>
- Date: Mon, 2 Dec 96 17:15:48 EST
- To: ietf-tls@w3.org
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