Skip to main content

Redaction of Potentially Sensitive Data from Mail Abuse Reports
RFC 6590

Yes

(Adrian Farrel)
(Pete Resnick)

No Objection

(Gonzalo Camarillo)
(Jari Arkko)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Wesley Eddy)

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

(Adrian Farrel; former steering group member) Yes

Yes ()

                            

(Pete Resnick; former steering group member) Yes

Yes ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection (2012-01-17)
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

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection ()

                            

(Peter Saint-Andre; former steering group member) No Objection

No Objection (2012-01-17)
I agree with other IESG members that this document seems informational, not standards track.

(Ralph Droms; former steering group member) No Objection

No Objection ()

                            

(Robert Sparks; former steering group member) No Objection

No Objection ()

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

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

(Sean Turner; former steering group member) No Objection

No Objection (2012-01-18)
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

No Objection (2012-01-15)
- 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

No Objection (2012-01-13)
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

No Objection ()