Re: [Gen-art] Gen-ART review of draft-ietf-marf-redaction-04

["Murray S. Kucherawy" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, January 10, 2012 6:44 PM
> To: [e-mail]; Murray S. Kucherawy; [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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