At 10:59 04-11-2011, 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
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
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
