On 1/16/12 3:44 PM, Murray S. Kucherawy wrote:
One of the security area directors has placed a DISCUSS on the above draft.
The working group needs to talk about the issue raised and determine how to
proceed.
The specific issue is that a simple hash over a key prepended to the data to be
redacted is not a strong security measure. Although we've mentioned that this
isn't much of a concern in our case in the proposed new text, the complaint has
reappeared. For example, the simple key-hash solution is susceptible to a few
simple recovery attacks.
Among other things, the concern is that doing something like this on the
standards track might lead future efforts to believe this mechanism is
sufficient for arbitrary data protection when it is not.
The proposals going forward appear to be:
a) Instead of a hash of key + data, replace the algorithm with HMAC, as defined
in RFC2104.
b) Add even more explanatory text so that the reader has it clear that we are
not attempting to completely secure something here, and acknowledge fully that
there are weaknesses in our algorithm. (The Wikipedia page for HMAC gives a
pretty good description of the comparison and attacks.)
c) Attempt to argue that it's good enough as it is, and that's how we want it.
I wanted to give you all the summary of the DISCUSSion on the IESG call
so that you can decide what you would like to do, but I'd also
personally like to understand the WG's position. So first on my questions:
The argument against (a) seems to be "HMAC is overkill because the data
can be retrieved other ways." Indeed, one of the (perhaps sarcastic)
claims was that ROT13 would be as useful as the simple hash. But if
there is any truth to these arguments, it leads me to ask: Why even
bother with redaction at all? Why not write a document that says,
"Redaction is stupid because all of the data can be retrieved by other
means and when you do it stupidly (like with X's), it screws up our
ability to do useful things with the report."? If it's truly a cardboard
box, why not say, "Don't put a lock on this!"?
If the answer is, "because people insist on putting a lock on", then I
think it's reasonable for someone to say, "Hey, the lock you're selling
to these people is either made of cardboard itself, or everyone has a
key, or whatever, and you had either better tell them about that, or
just sell them a real lock." In other words, I don't see any harm in
using HMAC, other than it's as much of a waste of time as doing a simple
hash or ROT13 or nothing at all.
So could someone explain why choosing HMAC is any more silly than doing
the hash? Or why there is any objection to doing HMAC (since it isn't
hard to do)?
That said, as of today's telechat, the IESG in general (and Stephen in
particular, who holds the DISCUSS) are fine with either (a) or (b) and
Stephen will clear his DISCUSS and I will approve the document once you
do one or the other in the doc. But do understand that (b) means
explaining that MD5 is a bad plan, and empty data is a bad plan, and all
of the other caveats of using a simple hash. If the WG is willing to put
that stff into security considerations, nobody is going to hold up the
document. On the other hand, we will be left wondering, cause it seems a
bit silly not to just use HMAC.
But it is up to the WG.
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
