Redaction of Potentially Sensitive Data from Mail Abuse Reports
RFC 6590

Note: This ballot was opened for revision 08 and is now closed.

(Adrian Farrel) Yes

(Pete Resnick) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2012-01-13 for -)
No email
send info
I am not a crypto expert, and thus do not know the severity of the attack vector in this case, but isn't there a plain text attack when encrypted material has a constant string included as seems to be the case here.

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2012-01-15)
No email
send info
- I don't get why this is not informational - where's the interop
consequence?

- While the idea of only listing JD is laudable, I think having a
concactable author is best so I'd suggest Murray be kept as an
author.

- Last para of section 1 - such correlation is not theoretical,
delete that word.

(Russ Housley) (was Discuss) No Objection

Comment (2012-01-18)
No email
send info
  Please reference RFC 4648, Section 4 for [Base64].
  More than one alphabet is available in RFC 4648.

(Dan Romascanu) No Objection

Comment (2012-01-17 for -)
No email
send info
This is a rather short and aparently straight-forward document, but it raised a couple of questions. None of them is that critical to deserve a blocking DISCUSS, but yet I would be glad if these were answered and clarified before approval and publication.

1. It is not clear why this document is on standards track. I do not know how to establish interoperability of implementations and thus what the critieria would be for advancement from Proposed Standard to Standard. Moreover the Abstract describes the scope in a rather non-commital manner (suggests one method for ... the report generator ... to redact or elide the sensitive portions of the message) - so this looks like a recommendation about one (good way) to perform redaction, but not the <standard way> of doing it.

2. I know too little about the operational model of configuring a report generator, so I was left wondering how are the first two recommendations implemented in practice: 

> 1.  Select an arbitrary string that will be used by an Administrative
       Management Domain (ADMD) that generates reports.  This string
       will not be changed except according to a key rotation policy or
       similar.  Call this the "redaction key".
>   2.  Identify string(s) (such as local-parts of email addresses) in a
       message that need to be redacted.  Call these strings the
       "private data".

Some text that clarifies how this is supposed to be implemented and configured in practice would be useful. 

(Peter Saint-Andre) No Objection

Comment (2012-01-17 for -)
No email
send info
I agree with other IESG members that this document seems informational, not standards track.

(Robert Sparks) No Objection

(Sean Turner) No Objection

Comment (2012-01-18 for -)
No email
send info
Updated (add the last two)

I agree with Stephen's and Russ' discuss: I think this needs to be an HMAC.

You probably don't need to specify an algorithm because it's not an interoperability issue, but it might be nice to point to RFC 6151 and 6194 for recent info on HMAC-MD5 and HMAC-SHA1.  It would stop people from trying to do something over kill like HMAC-SHA256.

If you're going to stick with the plain ole hash then pointing to 6151 and 6914 still is worth considering (i.e., MD5 bad).  

Probably worth a reference to RFC 4086 for the pseudo-random # issues.