Redaction of Potentially Sensitive Data from Mail Abuse Reports
RFC 6590
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
(Adrian Farrel; former steering group member) Yes
(Pete Resnick; former steering group member) Yes
(Dan Romascanu; former steering group member) No Objection
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.
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
I agree with other IESG members that this document seems informational, not standards track.
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Sean Turner; former steering group member) No Objection
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.
(Stephen Farrell; former steering group member) (was Discuss) No Objection
- 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.
(Stewart Bryant; former steering group member) No Objection
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.
(Wesley Eddy; former steering group member) No Objection