[as participant] As I've mentioned before, the idea of doing forensic reporting of messages that fail DKIM verification has been a very valuable tool in terms of interoperability testing between DKIM implementations. It's got value as well in showing signers how their mail is being altered in transit even when the signer and verifier are working properly (i.e., unanticipated mangling en route).
What's in draft-ietf-marf-dkim-reporting is essentially what I've developed and implemented almost since the beginning of the DKIM effort. The DKIM working group didn't pick it up, but since the forensic reports themselves are actually ARF-based, I brought the work here. It used to be part of draft-ietf-marf-authfailure-report but was broken out into its own document at (I think) our meeting in Maastricht. I haven't had much in the way of feedback on it except through targeted requests for reviews. When I finally got those, the suggestions I got were radically different from what I've implemented. Given that, I'd like to invite the working group to consider it from the ground up in order to build something that has consensus. So let's talk requirements. The idea is to enable a signer to request that a verifier, on finding a message that fails verification testing, send a message back showing the canonicalized forms of the header and body, the idea being that the signer would keep a copy of the same and thus be able to see what changed in transit. The mechanism of advertising that this is wanted needs to be simple and not add much burden to the existing system. (That's why I grafted it on to the key record in the DNS, which has to be retrieved anyway.) The authfailure-report draft creates the syntax for the report, so this draft only needs to be able to communicate the request for the report and its parameters. There are some obvious security considerations, such as being able to cause a storm of report mail if a lot of mail goes out all of which fails to validate. The interval stuff is in there to make it possible for the signer to mitigate such damage. There's an adjunct ADSP angle, which requests a report if ADSP says "this should be signed by the author domain" and it wasn't, even if all the signatures passed. The same requirements apply. I think it's really as simple as that. So if you don't like the dkim-reporting draft as it's written, how would you design something within those requirements? I think Steve and John commented on this before. I'll go dig up their old emails and comment on them as well, but I'll try to do so on this thread so it's all in one place. -MSK
_______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
