Hi John,
> Hi. I'm not one of the authors, but these issues have come up before.
Thank you - I appreciate the additional explanation and context.
> 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
That would definitely be useful, as I didn't find enough information in the
draft to help me understand what level of security is appropriate and why.
> 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.
As I noted in the review, the HMAC mechanism may not be appropriate, but
I do think that some of the draft content ought to be strengthened to prohibit
clearly wrong things such as the two examples in the review ("a" as redaction
key, CRC as hash/digest).
Thanks,
--David
> -----Original Message-----
> From: John Levine [mailto:[email protected]]
> Sent: Tuesday, January 10, 2012 11:38 PM
> To: [email protected]
> Cc: Black, David
> Subject: Re: [marf] Gen-ART review of draft-ietf-marf-redaction-04
>
> >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
