>Please resolve these comments along with any other Last Call comments you may >receive.
Hi. I'm not one of the authors, but these issues have come up before. >There are two important ways in which this technique could fail to effectively >hide >the redacted information: > - The secret string may inject insufficient entropy. > - The hashing/digest algorithm may be weak. Not really. These are feedback reports, in which a recipient system is sending back complaints that include copies of mail to the system that originally sent it. Any sender that keeps logs of outgoing mail, which is all of them these days, need only use the time stamps and sequence numbers in the headers, or any other per-recipient data in the header or body of the message, to look it up in their own logs to see who they sent it to. This is a fundamental limitation of feedback reports. I can tell you from experience that I've done this to figure out who to take off a list when their ISP tries to redact the complaint, and it's not hard. So in practice, even if the hash were extremely weak, nobody would care because there are easier ways to recover the address. Complaint reporting systems like Spamcop have been trying for years to redact complaints enough that senders can't "listwash" (remove complainers from spam lists), and experience has shown that it's basically impossible. This hack is really just to make life a little easier for senders who track complaint rates by recipient or recipient system, since 1 complaint each from N people means something different than N complaints from one person. It sounds like the security considerations didn't explain this adequately. Perhaps it would be better to fix the document to explain more clearly why redaction is fundamentally weak rather than to worry about what's akin to a steel lock on a cardboard box. R's, John _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
