Hi, Thanks for the response - I appreciate the perspective. > The comments are from a security perspective. To be candid, > redaction is silly as the email folks know how to get around > that. The secret key does not even have to be broken; a cookie in > the message would get you the information you want. The cost of > preserving the secrecy is not worth it in my opinion. At a minimum, I like John Levine's suggestion that the draft explain the level of security required for redaction in practice. Such an explanation could help illuminate whether the secure hash (the example in the draft uses SHA-1) is for obfuscation purposes vs. actual security. Absent such an explanation, I saw the use of a secure hash and inferred the existence of actual security requirements. If that was an incorrect inference, then text should be added to the draft to avoid having other readers make similarly incorrect inferences. Thanks, --David > -----Original Message----- > From: SM [mailto:sm@xxxxxxxxxxxx] > Sent: Wednesday, January 11, 2012 2:50 PM > To: Black, David > Cc: marf@xxxxxxxx; gen-art@xxxxxxxx; ietf@xxxxxxxx > Subject: Re: Gen-ART review of draft-ietf-marf-redaction-04 > > Hi David, > At 18:44 10-01-2012, david.black@xxxxxxx wrote: > >I am the assigned Gen-ART reviewer for this draft. For background on > >Gen-ART, please > > I appreciate that you have spent your time and effort in performing > the review. I find the review useful. > > > 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. > > > >[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. > > The comments are from a security perspective. To be candid, > redaction is silly as the email folks know how to get around > that. The secret key does not even have to be broken; a cookie in > the message would get you the information you want. The cost of > preserving the secrecy is not worth it in my opinion. > > Regards, > -sm > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf