ietf
[Top] [All Lists]

RE: Gen-ART review of draft-ietf-marf-redaction-04

2012-01-12 10:14:36
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(_at_)resistor(_dot_)net]
Sent: Wednesday, January 11, 2012 2:50 PM
To: Black, David
Cc: marf(_at_)ietf(_dot_)org; gen-art(_at_)ietf(_dot_)org; 
ietf(_at_)ietf(_dot_)org
Subject: Re: Gen-ART review of draft-ietf-marf-redaction-04

Hi David,
At 18:44 10-01-2012, david(_dot_)black(_at_)emc(_dot_)com 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf