Re: Fw: [Ipsec] I-D ACTION:draft-kelly-ipsec-ciph-sha2-00.txt

Hi Steve,

Thanks for the quick and detailed review.  Responses inline...

>I found 2.1.1 + 2.1.2 confusing.  2.1.1 says you can't have keys of other
>than length 256.  I might quarrel with that -- I'd definitely have used
>SHOULD NOT instead of MUST NOT -- but 2.1.2 tells you what to do if your
>key isn't 256 bits long.  I perceive no increase in security from padding
>a short key with zeros, nor do I understand why it's better to do a
>SHA-256 reduction on a long key before using it with HMAC rather than
>simply using the longer key directly.  And the notion of a variable key
>length function where the variable is constrained to exactly one value is
>a bit strange.

Part of the confusion probably derives from trying to combine PRF functionality into the same doc with authentication/integrity functionality (the latter of which was already in the doc), yet maintain differing requirements for the keys. Maybe that was a mistake. The intent was that for integrity/auth, you have to use a fixed length, as RFC2104 explicitly recommends against shorter keys, and this lanuage is consistent with RFC2403 and the other HMAC RFCs.

We added the PRF support after that text was written (rather than writing a separate doc), and in the interest of flexibility, chose to allow variable length keys.  I'm wondering now if that was a mistake, and we should have had a single position on key sizes. That would definitely simplify things.

As for padding short keys, it certainly adds no security. It is there to explicitly tell implementors what to do (so they don't instead hash the key, and use the output). It's called out for the sake of interoperability. 

As for using longer keys, I see now that I misread this line in 2104:

"Applications that use keys longer than B bytes will first hash the key using H and then use the resultant L byte string as the actual key to HMAC."

'B' refers to the block size (in this case, 512 bits), but I was thinking of 256 bits, in which case you would simply hash the key and use the output. Definitely my mistake, and I will fix this in the next rev.

>You might want to cite RFC 4634 as an Informative reference, since it has
>code, and 4231 since it also gives definitions and code points for other
>uses of HMAC-SHA-256.

Okay.

>Stepping back a bit, I personally would rather see a single RFC describing
>how to use a number of different hash functions with HMAC.  I could almost
>use a set of text editor substitution patterns to change this draft from
>SHA-256 to SHA-384 or SHA-512.  The core of such a document would be a
>table listing acceptable key sizes and truncation sizes for each function
>considered.  An appendix could list test vectors.

Russ just mentioned that NSA-B requires SHA-384 support, and I was looking at the draft to see if that could be cleanly dropped in - this might be one way to do it.  If there is general support for this approach, we can look at what it would take to re-spin the doc.

Thanks again for the review,

Scott

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec