Subject: [dmarc-ietf] Notes from DMARC session at IETF 95

From: "John Levine" <[email-masked]>
Date: 2 Jul 2013 16:15:33 -0000

To save time, here are the notes from the final DMARC session,
based on the current charter:

Mailing lists: One person demanded that all list software change to
preserve SPF and DKIM signatures.  Another person said to whitelist
based on A-R or List-ID headers until someone explained to him offline
that bad guys can forge them, and can sign forged headers.  A third
person noted that after three years, LinkedIn is still almost the only
domain anyone has seen sending p=reject mail to lists, and large ISPs
all do their own proprietary list whitelisting, so problems with the
clueless bouncing people off lists didn't happen.  Conclusion: nothing
to report.

Transitive trust: Senders just love transitive trust, receivers see no
benefit.  The extension in draft-baer-dkim-transitive has been
implemented by 14 senders but no receivers whose position (if you want
us to deliver your mail, make it easy for us) has been unchanged since
1987.  Conclusion: maybe publish it, but why bother.

Robust report mechanisms: After a year of ever more complex proposals
using https, https with client certificates, STARTTLS with client
certificates, DANE, PGP, SIP/TLS and COAP, the group gave up and
decided that DKIM signed email was as good as it gets.  Oh, and you
can skip sending aggregate reports for mail volume below a locally
determined threshold. Conclusion: nothing beyond existing language in
operations guide.

Display name attacks: Several people suggested complex MUA changes to
highlight or grey out various parts of messages, none implemented.  A
few people implemented draft-hammer-dmarc-display which extends DMARC
to strings in the display name that resemble domain names, but found a
large number of false alarms due to new domains like .web and was
trivially avoided using UTF-8 homographs (what IDNA prohibits from
domain names, see RFC 5892).  Conclusion: publish as experimental, 
because the part about MUAs and homographs is interesting.

Determining registered domain name: The group looked at
draft-sullivan-domain-origin-assert and draft-levine-orgboundary, neither
of which got any traction due to deep disagreements in the DNS
community about what boundaries mean.  The group gave up and kept
using the Mozilla public suffix list which, for all its faults,
actually exists.  Conclusion: nothing beyond existing language in
operations guide.

Operations guide: draft-ietf-dmarc-ops-12 finally in last call,
There haven't been any substantive changes since October 2013.
The appeal demanding that DMARC use a new RRTYPE was rejected.

R's,
John

---

From: Franck Martin <[email-masked]>
Date: Tue, 2 Jul 2013 18:22:14 +0000

The world according to John

"Crazy Franck"