>> I think the way forward is to explain why we don't need cryptographic >> security here, and why the specific hash function chosen doesn't >> matter, as long as the redacted value stays the same for the same >> unredacted input. And that's all. > > What do you think might be missing from the current Security Considerations > to nail this point home to the IESG's satisfaction? Basically, I thought we'd > done this already in -05.
I'd thought so, as well, so I don't know the answer to your question. I'll be happy to try tossing out some text. Another thought occurred to me, from what Pete has said: Pete's question is, "Why NOT use HMAC?" That's the wrong question; it's the IESG overstepping its authority, if they insist that that's the question. The IESG is objecting to what the working group has come up with, and the burden is on them to show that what we have is not sufficient FOR THIS USE CASE. The question isn't, "Why NOT use HMAC?" The correct question is, "For our use case, WHY REQUIRE HMAC? What does it give us that is necessary for our use case?" The amount of "security" in the redaction is ENTIRELY up to the redactor. Given this spec, the redactor is welcome to use HMAC if they want to -- if they or their lawyers think they need that level of confidence that it can't be deciphered. Depending upon the redactor's sensibilities, they are also welcome to use plain SHA1, or MD5, or CRC, or, hey, just base64-encode the plain-text string if all you want is to keep it away from idle eyes. It makes no sense for this spec to declare anything in this regard. Barry _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
