Hi Murray,
Thanks for the quick response.
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.
That sounds reasonable to me, and I like John Levine's suggestion to add
material to explain
more about the level of security that is appropriate for this problem space and
why. In light
of such an explanation, an HMAC-based mechanism could well be overkill.
- 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)
I have a hard time believing that the examples used in the review ("a" as the
redaction
key, CRC as the hash) are ever acceptable, and for that reason, I think a
couple of MUSTs
would be in order to prohibit that sort of nonsense. In particular:
- I think there ought to be a MUST minimum length requirement
on the redaction key string to prevent really short ones.
- I think use of a secure hash ought to be a MUST to prevent
use of CRC and other bad ideas.
That could be accompanied by additional guidance that may or may not be
"SHOULDs", e.g.,
suggest a SHA2 hash as a good secure hash, suggest use of a longer string than
the
minimum requirement.
[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.
That would be fine - introducing the concept of key rotation as a means to
reduce the impact of key
compromise accompanied by a reference to a longer explanation elsewhere seems
reasonable.
Thanks,
--David
-----Original Message-----
From: Murray S. Kucherawy [mailto:msk(_at_)cloudmark(_dot_)com]
Sent: Tuesday, January 10, 2012 11:41 PM
To: Black, David; ietf(_at_)cybernothing(_dot_)org;
gen-art(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Cc: marf(_at_)ietf(_dot_)org; presnick(_at_)qualcomm(_dot_)com
Subject: RE: Gen-ART review of draft-ietf-marf-redaction-04
-----Original Message-----
From: david(_dot_)black(_at_)emc(_dot_)com
[mailto:david(_dot_)black(_at_)emc(_dot_)com]
Sent: Tuesday, January 10, 2012 6:44 PM
To: ietf(_at_)cybernothing(_dot_)org; Murray S. Kucherawy;
gen-art(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Cc: david(_dot_)black(_at_)emc(_dot_)com; marf(_at_)ietf(_dot_)org;
presnick(_at_)qualcomm(_dot_)com
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf