> -----Original Message----- > From: david.black@xxxxxxx [mailto:david.black@xxxxxxx] > Sent: Tuesday, January 10, 2012 6:44 PM > To: ietf@xxxxxxxxxxxxxxxx; Murray S. Kucherawy; gen-art@xxxxxxxx; ietf@xxxxxxxx > Cc: david.black@xxxxxxx; marf@xxxxxxxx; presnick@xxxxxxxxxxxx > Subject: Gen-ART review of draft-ietf-marf-redaction-04 Hi David, thanks for the review. > [1] The first open issue is the absence of security guidance to ensure that this > redaction technique effectively hides the redacted information. The redaction > technique is to concatenate a secret string (called the "redaction key") to the > information to be redacted, apply "any hashing/digest algorithm", convert the output > to base64 and use that base64 string to replace the redacted information. > [...] > > I suggest a couple of changes: > 1) Change "any hashing/digest algorithm" to require use of a secure hash, and > explain what is meant by "secure hash" in the security considerations section. > 2) Require a minimum length of the "redaction key" string, and strongly suggest > (SHOULD) that it be randomly generated (e.g., by running sufficient output > of an entropy-rich random number generator through a base64 converter). > > For the latter change, figure out the amount of entropy that should be used > for redaction - the recommended string length will be larger because printable > ASCII is not entropy-dense (at best it's good for 6 bits of entropy in each > 8-bit character, and human-written text such as this message has significantly > less). > > From a pure security perspective, use of HMAC with specified secure hashes > (SHA2-family) and an approach of hashing the "redaction key" down to a binary > key for HMAC would be a stronger approach. I suggest that authors consider > approach, but there may be practical usage concerns that suggest not > adopting it. These are all good points. My gut reaction is to say that this is all good advice and entirely correct but probably goes a little far for the problem space we're trying to address. Thus, my inclination is to make the following changes (subject to WG consensus): - add all of this advice to Security Considerations, with forward references to it elsewhere in the document - make a SHOULD suggestion as to the minimum redaction key length (instead of a requirement) - make a SHOULD suggestion as to the type of hash to be used (instead of a requirement) Would those be sufficient? > [2] The second open issue is absence of security considerations for the redaction > key. The security considerations section needs to caution that the redaction key > is a secret key that must be managed and protected as a secret key. > Disclosure of a redaction key removes the redaction from all reports that used > that key. As part of this, guidance should be provided on when and how to change > the redaction key in order to limit the effects of loss of secrecy for a single > redaction key. Also a good point. I don't think this is the right place to introduce advice about key rotation and the like as those are well-discussed concepts, so instead Security Considerations can simply make reference to such material elsewhere. I'll go find some. I know there's stuff like that in RFC6376 (DKIM) but I'm sure there are better ones. > Editorial Nit: I believe that "anonymization" is a better description of what > this draft is doing (as opposed to "redaction"), particularly as the result is > intended to be correlatable via string match across reports from the > same source. Fair enough. We can add a sentence to that effect in the Introduction. To the MARF working group: Please let me know if the above suggestions suffice (reply only to the marf list, please). I will summarize and have a new version ready to publish when LC closes, and make sure David sees it around the same time. -MSK _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf