OBE if you go with the new path, but to follow up:
On 1/20/12 12:35 PM, Barry Leiba wrote:
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...
You will note that I quite carefully and explicitly split my questions
about the WG's intent from the IESG's DISCUSS questions. The question of
"Why NOT use HMAC?" was mine. The IESG did not ask that question and in
no way overstepped its authority. *I* thought it important to understand
why the WG was choosing not to use HMAC (and answer I really haven't
gotten, but again, it sounds like it's moot). The IESG DISCUSSion said,
"Either you need to use HMAC or explain the failings with H ('IHA') so
that readers understand what they do and do not get with H." That is
perfectly within bounds.
and the burden is on them to
show that what we have is not sufficient FOR THIS USE CASE.
Sorry, no. I suspect that the issue really is that the document does not
sufficiently define the use case to make it clear that H (or anything in
particular) is appropriate. That's why one of the solutions given was,
"Explain the limitations of H". If the use case was simply, "not easily
reversible by a human", BASE64 is perfectly reasonable and H is probably
overkill. But the document did not outline the use case and left open
the question of what was necessary.
The correct question is, "For our use case, WHY REQUIRE HMAC? What
does it give us that is necessary for our use case?"
Again, the IESG did not require you to use HMAC. It was either use HMAC,
or make clear the limitations of H. I think that defining the use case
would have also sufficed (though perhaps gotten some quizzical looks
about, "Then why not just use BASE64?", but without the DISCUSS.)
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.
I think that is correct and on what we all agree.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
