> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Scott > Kitterman > Sent: Friday, September 30, 2011 3:14 PM > To: [email protected] > Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt > > Does requiring the canonicalized header/body be included in the report obviate > the ability to remove data as described in paragraph 5? I think the fact that > these include data that one might want to redact is worth a mention in > security considerations. Also, if one is going to redact and then re- > canonicalize then providing the data is pointless. So if a sender wants to > fully redact information there's no benefit to including them. They should > only be included if they can be sent unmodified without violating the > receiver's privacy requirements.
The original intent of the canonicalized header/body fields is to allow a sender, who keeps the same data at the time of signing, can compare it against the receiver's copy of the same data to tell how the signed part of a message was altered in transit. When doing DKIM debugging, redaction clobbers any hope of finding the real problem. This is definitely appropriate for coverage in Security Considerations. With respect to the warning that most implementations will just report "other" a lot of the time, I think it's fair to say that's fine: For sites that agree between themselves that they trust each other and trust the transmission channel, they can agree to send unredacted, detailed reports, and this document says how to do so; for those that do not and have privacy concerns, the spec should accommodate those cases as well. -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
