Subject: [marf] Working Group Last Call on draft-ietf-marf-redaction

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 4 Nov 2011 11:59:03 -0700

This message starts a two-week Working Group Last Call on the redaction document, ending on 11/18.  Alessandro sent some text for consideration so those are already included in the WGLC.  Please submit any further review comments before then.

Thanks!

-MSK

---

From: "Mykyta Yevstifeyev (М. Євстіфеєв)" <[email-masked]>
Date: Sat, 05 Nov 2011 07:16:21 +0200

Hello,

Some comments on draft-ietf-marf-redaction:

I see this document's intended status is Informational.  I wonder why it 
isn't BCP, since the doc. tries to establish the recommended practice.

In Section 2: should it be mentioned that the 1st part of 
"multipart/report" message with "feedback-report" report-type should 
have a notice of some data being redacted?

References should be split into normative and informative.  I suppose 
[ARF] and [MIME] should go as normative and [DKIM-REPORTING] as informative.

Mykyta Yevstifeyev

04.11.2011 20:59, Murray S. Kucherawy wrote:
>
> This message starts a two-week Working Group Last Call on the 
> redaction document, ending on 11/18.  Alessandro sent some text for 
> consideration so those are already included in the WGLC.  Please 
> submit any further review comments before then.
>
> Thanks!
>
> -MSK
>
>
>
> _______________________________________________
> marf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/marf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 5 Nov 2011 21:53:49 -0700

Hello Mykytka,

BCP is possibly appropriate.  I’ll see what our AD thinks.

There isn’t currently a mechanism for indicating the report contains redacted segments.  So far, the sites that have implemented this don’t appear to have a need for doing so.  I’m not sure it’s necessary; the goal is to have the redacted segments be invariant when the original strings are also invariant, which is accomplished without the need for signaling redaction.  I’d like to hear other opinions on this point though.

I agree on the references split.  However, ARF is the only normative one; the others are informative.

Thanks,
-MSK

From: [email-masked] [mailto:[email-masked]] On Behalf Of "Mykyta Yevstifeyev (?. ?????????)"
Sent: Friday, November 04, 2011 10:16 PM
To: [email-masked]
Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-redaction

Hello,

I see this document's intended status is Informational.  I wonder why it isn't BCP, since the doc. tries to establish the recommended practice.

In Section 2: should it be mentioned that the 1st part of "multipart/report" message with "feedback-report" report-type should have a notice of some data being redacted?

References should be split into normative and informative.  I suppose [ARF] and [MIME] should go as normative and [DKIM-REPORTING] as informative.

Mykyta Yevstifeyev

Thanks!

-MSK

marf mailing list

[email-masked]<mailto:[email-masked]>

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 06 Nov 2011 12:36:25 +0100

On 06/Nov/11 05:53, Murray S. Kucherawy wrote:
> 
> There isn’t currently a mechanism for indicating the report contains
> redacted segments.  So far, the sites that have implemented this don’t
> appear to have a need for doing so.  I’m not sure it’s necessary; the
> goal is to have the redacted segments be invariant when the original
> strings are also invariant, which is accomplished without the need for
> signaling redaction.  I’d like to hear other opinions on this point
> though.

Redaction obviously breaks DKIM.  Sites that rely on that for telling
whether a message really originated at theirs may confuse redacted
messages and spoofs.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 6 Nov 2011 23:35:01 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Sunday, November 06, 2011 3:36 AM
> To: [email-masked]
> Subject: Re: [marf] Working Group Last Call on draft-ietf-marf- redaction
> 

Are there actually sites that try to do that, or is this a solution looking for a problem?

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 07 Nov 2011 12:57:36 +0100

On 07/Nov/11 08:35, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>> 

The latter one, AFAIK.  More precisely, that is a known problem.  A
solution is the "hybrid approach" in Section 4.4 of the CFBL BCP.

---

From: SM <[email-masked]>
Date: Mon, 07 Nov 2011 13:22:11 -0800

At 10:59 04-11-2011, Murray S. Kucherawy wrote:
>consideration so those are already included in

 From Section 2:

   "4. Compute a digest of that string with any hashing/digest algorithm
       such as SHA1"

A reference to RFC 6234 could be added for "SHA".  I'll leave it to 
the security folks to determine which algorithm to pick.  Using any 
hashing/digest algorithm will be viewed as unsecure.  It would be 
better to mention the minimally acceptable one.

I suggest separating Section 3 into different sections, one for 
security and the other for privacy.  The current section only covers 
privacy.  Does redaction (see algorithm) create any security issues?

 From Section 3:

   "If further protections are required, implementors may wish to
    consider establishing legal contracts or other non-technology-based
    agreements between the relevant entities."

This is a technical specification.  Legal contracts do not increase 
the level of privacy.  It would be better to remove that sentence.  I 
suggest focusing on the information disclosure angle if the aim is to 
have a privacy considerations section.

BTW, the title of the draft is "Redaction of Potentially Sensitive 
Data from Mail Abuse Reports".  My reading is that the algorithm is 
to only redact the local-part of an email address (message header and 
body).  Most, if not all, the WG participants know how to circumvent 
that. :-)  The title could be "redaction of email addresses from mail 
abuse reports".

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 7 Nov 2011 14:00:11 -0800

Hi SM,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Monday, November 07, 2011 1:22 PM
> To: [email-masked]
> [...]

> that. :-)  The title could be "redaction of email addresses from mail

The algorithm presented could be used to redact anything in particular.  Although it's certainly true that email addresses or even just their local-parts are the likely targets, the presented algorithm could work equally well to redact full names.  (And if one is redacting local-parts but not email addresses, I have to wonder "why"...)

-MSK

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 7 Nov 2011 23:11:18 +0100

> "4. Compute a digest of that string with any
> hashing/digest algorithm such as SHA1"

> A reference to RFC 6234 could be added for "SHA".

IMHO any hash including I-D.eastlake-fnv and MD5
will do.  The redaction I-D does not claim that
SHA-1 is still considered as a "secure hash", if
I understood the I-D correctly, it only suggests
to use something more convoluted than "xxxxxx".

> My reading is that the algorithm is to only
> redact the local-part of an email address
> (message header and body).

NAK, the sensitive part of [email-masked]
could be "catchall" instead of "anything".

> The title could be "redaction of email addresses
> from mail abuse reports".

For "John Doe" <[email-masked]> the private
stuff could be "John Doe", "secret", and "catchall".

In the EU this is anyway governed by privacy laws.
Static IPs can be also private data, this is not
only about email addresses.

-Frank

---

From: SM <[email-masked]>
Date: Mon, 07 Nov 2011 14:53:18 -0800

Hi Murray,
At 14:00 07-11-2011, Murray S. Kucherawy wrote:
>The algorithm presented could be used to redact anything in 
>particular.  Although it's certainly true that email addresses or 
>even just their local-parts are the likely targets, the presented 
>algorithm could work equally well to redact full names.  (And if one 
>is redacting local-parts but not email addresses, I have to wonder "why"...)

The flippant answer is that it keeps the lawyers happy. :-)

If the aim is to redact sensitive information, it is up to the sender 
to identify the parts of the text that contain personal identifiers 
and apply the algorithm.  That would cover full names.  The term 
"personally identifiable information" is generally used.  I prefer 
not to get into that to avoid having to explain how to identify such 
information in a message.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 7 Nov 2011 15:36:23 -0800

> Sent: Monday, November 07, 2011 2:53 PM
> To: [email-masked]

Right, and I don't think we should either.  Providing the mechanism is sufficient.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 08 Nov 2011 09:45:19 +0100

On 07/Nov/11 23:00, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of SM
>>> Alessandro sent some text for consideration so those are
>>> already included in

Wouldn't it be odd to consider that text after WGLC?

>> BTW, the title of the draft is "Redaction of Potentially
>> Sensitive Data from Mail Abuse Reports".  My reading is that the
>> algorithm is to only redact the local-part of an email address

The spec says "such as" local-parts of email addresses, in
parentheses.  It is a way to indicate by example --apparently better
than the "atomistic" wordings we tried.

Some full examples of redacted messages would better the I-D.

> algorithm could work equally well to redact full names.

Indeed, in the text I sent for consideration, I tried to identify
further PII explicitly.

> (And if one is redacting local-parts but not email addresses, I
> have to wonder "why"...)

Since it is not PII, it can be safely left in place.  (Please note
that "safely" addresses legal concerns, not security.)  Having domain
names is often necessary to process messages properly.  Hence, leaving
them alone allows treatment even without full un-redacting
capabilities, which is consistent with the claim that ARF messages are
also human-readable.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 8 Nov 2011 10:47:18 -0800

> Sent: Tuesday, November 08, 2011 12:45 AM
> To: [email-masked]

I don't understand that question.  Your comment was made before or during WGLC, so it's considered for the revision.  I explicitly included it by saying so.

> Some full examples of redacted messages would better the I-D.

Fair enough.

> capabilities, which is consistent with the claim that ARF messages are

If you're doing any redacting at all using the proposed method, you're already replacing some part of the message (arguably the most interesting part) with a string of what a user will see as gibberish.  I don't see how doing it twice makes it any less human-readable than it already is.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 09 Nov 2011 09:51:49 +0100

On 08/Nov/11 19:47, Murray S. Kucherawy wrote:
> I don't understand that question.  Your comment was made before or
> during WGLC, so it's considered for the revision.  I explicitly
> included it by saying so.

Yes, but nobody commented on it.

>> Since it is not PII, it can be safely left in place.  (Please
>> note that "safely" addresses legal concerns, not security.)
>> Having domain names is often necessary to process messages
>> properly.  Hence, leaving them alone allows treatment even
>> without full un-redacting capabilities, which is consistent with
>> the claim that ARF messages are also human-readable.
> 
> If you're doing any redacting at all using the proposed method,
> you're already replacing some part of the message (arguably the
> most interesting part) with a string of what a user will see as
> gibberish.  I don't see how doing it twice makes it any less
> human-readable than it already is.

Since the domain of a recipient address doesn't necessarily match that
of the report sender, nor (part of) the Reporting-MTA, naive ESPs
might be unable to understand /why/ they're receiving those overly
redacted complaints.  This is especially relevant when the FBL
subscription was skipped, or didn't involve disclosing all the
affected domain names.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 14 Nov 2011 21:49:18 -0500

> Yes, but nobody commented on it.

Does that tell you something?
Should it?

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Nov 2011 19:14:40 -0800

Hi SM, thanks for providing some feedback.

> A reference to RFC 6234 could be added for "SHA".  I'll leave it to the
> security folks to determine which algorithm to pick.  Using any

Rather than RFC6234, I'm changing this to "such as one defined in FIPS-180-3-2008", since that's the SHA reference DKIM used.  I've copied the actual reference information over.

> privacy.  Does redaction (see algorithm) create any security issues?

Yes, your suggested split is appropriate, I think.  The IESG might find the current section name a little unusual.

The most common issue brought up when using message digests in a protocol is the impact of collisions.  I've added a paragraph about that post-split.

> This is a technical specification.  Legal contracts do not increase the
> level of privacy.  It would be better to remove that sentence.  I

I've changed it to "establishing out-of-band arrangements between the relevant entities."

> BTW, the title of the draft is "Redaction of Potentially Sensitive Data
> from Mail Abuse Reports".  My reading is that the algorithm is to only
> redact the local-part of an email address (message header and body).
> Most, if not all, the WG participants know how to circumvent that. :-)
> The title could be "redaction of email addresses from mail abuse
> reports".

The algorithm can redact anything, though the local-part is the obvious and most common target.  In that sense, I think the present title is more appropriate.  Are there other opinions about that?

-MSK