Revisiting this very old thread to get some momentum going... > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Alessandro Vesely > Sent: Saturday, March 12, 2011 4:29 AM > To: [email protected] > Subject: Re: [marf] draft-jdfalk-marf-redaction > > What strings should be identified as private data? I'd suggest to > redact atoms, rather than strings that contain special characters.
"atoms" in the ABNF sense? Or what exactly do you mean here? > How do consumers identify redacted parts? Are they expected to be > able to verify DKIM signatures after replacing the redacted parts? > (Don't they need the redaction key to check they identified each part > correctly?) Why might there be a need to identify redacted parts? That sounds like a machine parsing problem. Is there some reason a parser would need to identify segments that were redacted? Certainly submitting something redacted means DKIM can't be verified. But I don't think that's a concern; there has to be some understanding that returning redacted information prevents any kind of useful DKIM activity on the original (returned) message. The authfailure-report document also covers this. If a consumer had the redaction key, then there's not much point in redacting at all. > What about line length limits? Should the encoded hash be truncated > to the length of the redacted token? No; if you redact one byte, then you truncate the hash at one byte. Huge collision worry. > After private data has been identified, should it be redacted in the > whole message, that is, including the body? For example, I think I > can hide some text <[email protected]>. > Should we standardize such practice, since we are at it? I think I'd prefer to let the report generator decide. > We should explicitly say what parts should never be redacted. This > includes header fields names, boundaries, and most parts of /some/ > fields, for example DKIM signatures possibly except z=, Received > fields possibly except "for" clauses. I'd be fine with limiting it so that header field names, or any parts of the message that constitute structure (media types, for example) SHOULD NOT be redacted. Or, at least, I can't see that being a problem. > As a security consideration, I'd mention that the scope of redaction > is limited to casual eavesdropper, including low-privileged abuse > teams staffers. Using logs or purposely added opaque fields, one can > learn who were the original recipients, which is the reason why abuse > messages are sent in the first place. That sounds reasonable as well. _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
