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

From: Alessandro Vesely <[email-masked]>
Date: Tue, 01 Nov 2011 10:30:22 +0100

On 31.10.2011 21:27, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>>
>> 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.)
> 
> 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]

Actually, I meant

   "redacted-encoding1" "@" "redacted-encoding2" "." "redacted-encoding3"

> That seems excessive.

Yes, definitely.  Perhaps, step 6 could be changed so as to read

   6.  Replace each atom of the private data string with the characters at
       the corresponding positions in the encoded hash string, when
       generating the report.

Thus "<[email-masked]>" becomes "<[email-masked]>" if the encoded hash is ABCD...,
but easiness is lost.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 Nov 2011 02:55:45 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Tuesday, November 01, 2011 2:30 AM
> To: [email-masked]
> Subject: Re: [marf] draft-jdfalk-marf-redaction
> 
> Actually, I meant
> 

So now we have to say which atoms get encoded and which don't.  It's getting pretty complicated.

> [...]

Definitely.

We also have to consider that user full-names might need redaction.  "Murray S. Kucherawy" is six atoms, for example, and we'd have to specify rules there too.

I think this way lies madness.  As long as the redaction procedure is applied consistently, both sides get what they want.  I think that's as far as we should go.

Are there any other points to cover here, or is a WGLC in order?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 Nov 2011 03:45:32 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Tuesday, November 01, 2011 2:56 AM
> To: [email-masked]
> We also have to consider that user full-names might need redaction.
> "Murray S. Kucherawy" is six atoms, for example, and we'd have to
> specify rules there too.

Er, it's four atoms.  But still.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Tue, 01 Nov 2011 08:08:57 -0400

In
<[email-masked]>,
on 11/01/2011

>Er, it's four atoms.  But still.

"Murray", "S" and "Kucherawy"; I count 3.

-- 
     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: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Tue, 01 Nov 2011 08:05:28 -0400

In
<[email-masked]>,
on 10/31/2011
   at 01:27 PM, "Murray S. Kucherawy" <[email-masked]> said:

>Possibly, but since "[email-masked]" consists of four atoms, 

Three.

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

[redacted-encoding1]@[redacted-encoding2].[redacted-encoding3]

>That seems excessive.

Yes.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 01 Nov 2011 15:48:41 +0100

> getting pretty complicated.

RFC 5322 is complicated, using its ABNF we simplify our text.

> "Murray S. Kucherawy" is six atoms, for example, and we'd have to specify
> rules there too.

Not necessarily, it can be replaced by "BCDEFGHI.KLMNOPQRST", ignoring quoted
strings.

> I think this way lies madness.  As long as the redaction procedure is
> applied consistently, both sides get what they want.  I think that's as
> far as we should go.

Consider this string:

   To: "Murray S. Kucherawy" <[email-masked]>

and a possible redaction of it:

   To: "BCDEFGHI.KLMNOPQRST" <[email-masked]>

Is that sufficiently protective and non-disruptive?  I agree it is uselessly
difficult to specify how to do something like that, but I would at least add
some (possibly real) examples.

> Are there any other points to cover here, or is a WGLC in order?

Perhaps, it is useful to mention that

  An abuse-reporting policy should specify the concept of "recipient(s)" of
  abusive messages, clarifying how that may depend upon who signaled the
  abuse and relevant domain names.  Usually, it is the recipient's data that
  needs to be concealed, not the sender's.  In particular, the following
  header fields contain mailbox or addr-spec tokens, and hence are likely to
  need redaction:

  * To,
  * CC,
  * the "for" clause of Received,
  * Delivered-To,
  * [add to taste].

  If the From: header field contains a recipient's address, it may need
  redaction as well.  In this case, it is important to replace it
  consistently so that the matching can still be recognized.

  In addition, unstructured fields, like Subject:, and the body may be
  searched for strings that match the recipient's name, surname, the
  local-part, or other private data that the server knows and thus might
  appear to be leaking from it if not redacted.

Finally, the I-D lacks a one-liner section for terminology, e.g.

  2.  Terminology

     The terms local-part, addr-spec, [more?], are defined in [MESSAGE].

Where [MESSAGE] would point to RFC 5322, to be added.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 Nov 2011 14:10:10 -0700

> Sent: Tuesday, November 01, 2011 7:49 AM
> To: [email-masked]

I don't see how referencing RFC5322 clarifies your proposed scheme much.  You seem to concur below.

> some (possibly real) examples.

There's a lot of needless complexity here.  The main point is that the agent receiving the report doesn't need to know exactly what's been redacted.  All it cares about is that the content of the redacted From and the unredacted From are isomorphic, so that behavioural patterns could be detected and reported.  So these rules only really apply to the agent generating the report, and then the only important point is that it do so consistently.    I think the current text says that already.  So rather than come up with complex redaction schemes including guidance on how to select redacted segments right down to specific atom patterns, we only need to advise that the report generator do so uniformly and consistently, and the goal is met.  Let those agents do so however they want.

> Where [MESSAGE] would point to RFC 5322, to be added.

All of that sounds reasonable to me.  JD?

-MSK