Subject: Re: [marf] draft-jdfalk-marf-redaction

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 29 Oct 2011 23:42:25 -0700

Revisiting this very old thread to get some momentum going...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Saturday, March 12, 2011 4:29 AM
> To: [email-masked]
> 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-masked]>.
> 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.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 29 Oct 2011 23:51:58 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of J.D. Falk
> Sent: Tuesday, March 08, 2011 9:43 AM
> To: Message Abuse Report Format working group
> Subject: [marf] draft-jdfalk-marf-redaction
> 
> I was in the mood for xml the other day, so I took section 10 of draft-
> ietf-marf-dkim-reporting and added the minimum necessary additional
> text and formatting to make it a stand-alone draft:
> 
> http://tools.ietf.org/html/draft-jdfalk-marf-redaction-00
> 
> (Oops, just noticed I forgot to acknowledge the original authors.  Many
> apologies; that'll be fixed in the next version.)
> 
> My thought is that by making this a stand-alone Informational RFC,
> it'll be easy to reference from other documents.
> 
> Any thoughts?

Commenting on the -01 version:

As Alessandro pointed out, one might want to redact anything in the message, not just local-parts.  Section 2 already says that, but the paragraph at the end also seems focused on the idea that user-ids are all that gets covered.  That paragraph should be more generic.

Also, Section 2 should include a SHOULD NOT with respect to redacting portions of the message that define its structure, namely header field names and parts of the MIME structure like boundary strings and media types.

Section 3 should include a paragraph reflecting Alessandro's point about privileged users (e.g., users with access to logs) possibly being able to deduce private information in correlation with redacted bits of a message.

The IESG lately cringes at specific endorsement of SHA1 or MD5. I suggest changing "SHA1" to something more general like "any acceptable hash/digest algorithm".

Since this technique is in production use in a few places (Mike from Facebook said so earlier in this thread, for example, and we know of other MAAWG members doing so as well), and since the target status is Informational, maybe this one is also getting close to being WGLC-able.  Comments?

-MSK

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Sun, 30 Oct 2011 16:18:31 -0500

In
<[email-masked]>,
on 10/29/2011
   at 11:42 PM, "Murray S. Kucherawy" <[email-masked]> said:

>"atoms" in the ABNF sense?

Presumably in either[1] the RFC 5321 or the RFC 5322 sense:

   Atom           = 1*atext

   atext           =   ALPHA / DIGIT /    ; Printable US-ASCII
                       "!" / "#" /        ;  characters not including
                       "$" / "%" /        ;  specials.  Used for
atoms.
                       "&" / "'" /
                       "*" / "+" /
                       "-" / "/" /
                       "=" / "?" /
                       "^" / "_" /
                       "`" / "{" /
                       "|" / "}" /
                       "~"

   atom            =   [CFWS] 1*atext [CFWS]

[1] Differing in whether to allow CFWS

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2        <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 30 Oct 2011 15:05:59 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Shmuel Metz
> Sent: Sunday, October 30, 2011 2:19 PM
> To: [email-masked]

Yes, I know what "atoms" means, but I don't understand why it would be appropriate to require that one redact each atom individually.  That's why I'm asking.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 31 Oct 2011 19:20:03 +0100

On 30.10.2011 23:05, Murray S. Kucherawy wrote:
> Yes, I know what "atoms" means, but I don't understand why it would be
> appropriate to require that one redact each atom individually.  That's why
> I'm asking.

IIRC, I was trying to make sense of

   2.  Identify string(s) (such as local-parts of email addresses) in a
       message that need to be redacted.  Call this the "private data".

It is the most difficult part of the task.  Doing it too liberally may make
the whole header unusable, and redacting each atom individually is an easy
criterion to avoid that.  (Well, it looks easy to specify, at least.)

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Mon, 31 Oct 2011 12:08:59 -0500

In
<[email-masked]>,
on 10/30/2011
   at 03:05 PM, "Murray S. Kucherawy" <[email-masked]> said:

>Yes, I know what "atoms" means, but I don't understand why it would
>be appropriate to require that one redact each atom individually. 
>That's why I'm asking.

You asked '"atoms" in the ABNF sense?  Or what exactly do you mean
here?',[1]. You didn't ask why it was appropriate to redact only
atoms.

[1] RFC 5234 doesn't define atom.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 31 Oct 2011 13:27:29 -0700

> Sent: Monday, October 31, 2011 11:20 AM
> To: [email-masked]

Possibly, but since "[email-masked]" consists of four atoms, you end up with something like this if you want to encode an email address:

[redacted-encoding1][redacted-encoding2][redacted-encoding3][redacted-encoding4]

That seems excessive.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 31 Oct 2011 14:46:19 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jacqui Caren-home
> Sent: Sunday, March 13, 2011 3:30 AM
> To: [email-masked]
> I would recommend that redaction be based upon the anti-spam score the
> orginal message gets and what level of trust you place in the MSP.
> 
>  > Just mumbling...
> 
> Given the fiasco while trying to report abusive (inline image heavy to botnet/scraper
> spamtraps) spam to messagelabs I would recommend redaction of all identifying marks
> when dealing with a spamtrap of obvious spam.
> This includes the "name" part of the recipent which is being used by some commercial
> spammers (including the said ML spammer) as a unique "tag" back into thier list. Such
> tricks are being used by spammers and some bulk MSP's who buy in lists and wish to
> detect the spamtraps hit. Even worse are the list cleanse businesses who are using said
> tricks to generate lists of know spamtraps for resale or reuse to cleanse commercial
> list data. I am afraid that detecting spamtraps is big business and people like ML
> seem to be quite happy to help paying "customers" detect them.

I'm inclined to say the choice of when and what things to redact should be left as a policy decision.  If we have suggestions or examples, that's fine to include in an informational sense, but we should go no further.