Subject: [marf] I-D Action: draft-ietf-marf-redaction-06.txt

From: [email-masked]
Date: Mon, 23 Jan 2012 08:59:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Abuse Reporting Format Working Group of the IETF.

	Title           : Redaction of Potentially Sensitive Data from Mail Abuse Reports
	Author(s)       : J.D. Falk
                          M. Kucherawy
	Filename        : draft-ietf-marf-redaction-06.txt
	Pages           : 8
	Date            : 2012-01-23

   Email messages often contain information that might be considered
   private or sensitive, per either regulation or social norms.  When
   such a message becomes the subject of a report intended to be shared
   with other entities, the report generator may wish to redact or elide
   the sensitive portions of the message.  This memo suggests one method
   for doing so effectively.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-marf-redaction-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-redaction-06.txt

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 23 Jan 2012 20:58:01 +0100

> 	Filename        : draft-ietf-marf-redaction-06.txt

I think that approach definitely solves the previous issue.

Two points:

First, step 4 of Section 2 could be merged with (or moved right after)
step 1, as it involves the target set of the transformation and hence
is part of it.  The example that recalls SMTP requirements for local
parts could be moved to Section 3 (BTW, the maximum length of 64 bytes
could also be mentioned, so that both truncation and encoding become
part of the transformation.)  The point is that such choices logically
belong to step 1, since they are not based on the output of the
transformation of a given piece of private data.

Second, Section 3 could mention that some transformations use a secret
key and thereby recover the definition of "redaction key".  All or
some of the Key Management section, as well as the statement on its
reasonable length, could then be recovered.

jm2c

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Jan 2012 12:13:17 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Monday, January 23, 2012 11:58 AM
> To: [email-masked]
> Subject: Re: [marf] I-D Action: draft-ietf-marf-redaction-06.txt
> 
> is part of it.
> The example that recalls SMTP requirements for local

I've already posted -06, unfortunately.

I think it's better to just change "contains" to "can contain", and similarly "includes" to "can include".  The specific rules for different tokens (e.g., local-parts vs. domain names) might be a little different.  For example, base64 won't work universally on domain names, but base32 would.  So the transformation needs to meet certain requirements, and so does the encoding.  But those two requirement sets come from different places, so I prefer the partitioning as we have it.

As for the length, I think we should be more general and just say there may be other constraints that also need to be observed in the replacement.

> key and thereby recover the definition of "redaction key".  All or some
> of the Key Management section, as well as the statement on its

I don't think we want to get into the mechanics of various methods at all.  To some extent, that's what got us into trouble in the first place, and also those issues are very well described and understood in existing documentation.  We don't need to repeat any of that here.

Since Stephen hasn't responded to -06 yet, I'll see if it's okay to do a -07 with the above or if we should stick with what we have.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Mon, 23 Jan 2012 16:03:10 -0500

> Since Stephen hasn't responded to -06 yet, I'll see if it's okay to do a -07 with
> the above or if we should stick with what we have.

Revs are cheap; there's no reason we shouldn't post another version if
consensus is for it.

But consensus is not yet for it -- we've only heard from two
participants.  Others, please comment on this thread now.

Barry, chair and shepherd

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Mon, 23 Jan 2012 13:53:28 -0500

In <[email-masked]>, on 01/23/2012

>ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-redaction-06.txt

Should some text from 1.  Introduction be replicated in the Abstract
to keep the IESG happy?

-- 
     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: SM <[email-masked]>
Date: Mon, 23 Jan 2012 15:39:57 -0800

At 12:13 23-01-2012, Murray S. Kucherawy wrote:
>I think it's better to just change "contains" to "can contain", and 
>similarly "includes" to "can include".  The specific rules for 
>different tokens (e.g., local-parts vs. domain names) might be a 
>little different.  For example, base64 won't work universally on 
>domain names, but base32 would.  So the transformation needs to meet 
>certain requirements, and so does the encoding.  But those two 
>requirement sets come from different places, so I prefer the 
>partitioning as we have it.
>
>As for the length, I think we should be more general and just say 
>there may be other constraints that also need to be observed in the 
>replacement.

That sounds fine.

>I don't think we want to get into the mechanics of various methods 
>at all.  To some extent, that's what got us into trouble in the 
>first place, and also those issues are very well described and 
>understood in existing documentation.  We don't need to repeat any 
>of that here.

+1

Regards,
-sm

---

From: "John Levine" <[email-masked]>
Date: 23 Jan 2012 23:52:50 -0000

>I think it's better to just change "contains" to "can contain", and similarly
>"includes" to "can include".  The specific rules for different tokens (e.g.,
>local-parts vs. domain names) might be a little different.  For example, base64
>won't work universally on domain names, but base32 would.  So the transformation
>needs to meet certain requirements, and so does the encoding.  But those two
>requirement sets come from different places, so I prefer the partitioning as we
>have it.
>
>As for the length, I think we should be more general and just say there may be
>other constraints that also need to be observed in the replacement.

Sure.  While you're at it there's a typo, date -> data.

>I don't think we want to get into the mechanics of various methods at all.

Please let that sleeping dog lie.

R's,
John