> 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"
Yes, as Murray has said. But this reminds me, and perhaps you (Pete) can talk with Stephen and Sean about this: Several (as opposed to a few) IETF meetings ago, there was discussion (from a presentation by EKR, if I remember correctly) about the usefulness of defining what is *specifically* an INSECURE hash. Do something like, say, re-define MD5 and call it "IHA-1" (Insecure Hash Algorithm 1). Then it could be used in cases where a hash was needed, but there was no security need for the hash, and no one would say, "Oh! Oh! You can't use MD5! It's too weak and vulnerable! Oh!" (Think Arnold Horshack here, for those young enough to understand the reference.) This is exactly one of those use cases. But we never defined any IHA-1, and so we have to either say, "Use any damned hash you want (CRC included, to use David Black's silly example from the GenART review), because it doesn't matter, and if *you* want to make it more secure, because, you know, your local policy demands it, well, then, that's fine, and you know how to do it," or else succumb to pressure to kick it into crypto orbit with HMAC because "It's not hard." Go back and read EKR's slides from SAAG at IETF 73: http://www.ietf.org/proceedings/73/slides/saag-0.pdf ...and tell me that it really matters that we say *anything* about what hash to use. Barry , 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 _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
