Dmarc Status PagesDomain-based Message Authentication, Reporting & Conformance (Active WG)
Art Area: Adam Roach, Alexey Melnikov, Ben Campbell | 2014-Aug-11 —Chairs:
IETF-99 dmarc minutes
Session 2017-07-20 0930-1200: Berlin/Brussels - Audio stream - dmarc chatroom
DMARC notes from IETF 99 1. Introduction & administrative Barry: New mailing list policy: if you post from a p=reject address and it causes unsubscribes, you will be asked to post from a different address. If you don't, your address will be blocked from posting. 2. Report from Hackathon project Kurt: Did testing, builds, new forwarder, fastmail perl milter advanced. Several other implementations in progress. Will have updates at M3AAWG in October (Toronto). Barry: Plan another hackathon weekend before IETF 100 in Singapore. 3. Report about handling IETF Mailman Kurt: Planning to integrate ARC into IETF's Mailman 2, looking for stability for what's on the wire, packaging in progress. Aiming for early September. Alexey: Also planning workaround that rewrites addresses, start experimenting in September. Different rewriting than existing patches. Barry: Need to experiment turning mitigations on and off to see how recipient systems react to the ARC signing. 4. Open issues in the ARC specs - Include discussion of document status (Standards Track vs Experimental) Kurt: Settled issues: - AAR need not be signed - combine cv=invalid/fail into fail - add policy failures into A-R - combine multiple A-R into a single AAR Bron: What do you report from temporary vs. permanent DNS failures? Kurt: likely defer with 421 code, or eventually reject like any other long temp failure. Kurt: Language updates for a revised draft in progress. Working on language to handle multiple signing algorithms. Language for trust within a trust boundary. Whether to signal whether a system participates? Probably not, can't trust self-assertions. Questions about AAR content and format. Barry: When ready for WGLC? Kurt: New draft tomorrow, hope to be ready for LC in a week. 4a. Document status discussion Dave Crocker: Suggest experimental for now because the operational issues associated with the chain of signing aren't known. Revisit when ready for a BCP. Kurt: Have enough implementations to make a proposed standard. Murray: If it's WGLC in a week, I'd prefer experimental. If we take more time, then proposed standard. Andreas Schultze: Not being Standards Track made some not want to implement DMARC. Maarten Aertsen: Will small operators implement ARC at all? Kurt: There is some interest. Seth Blank: We did ARC training at M3AAWG; major receivers put together a bootstrap whitelist of 2000 intermediaries for small receivers, will publish it. It really is an experiment. Barry: What will give best implementation experience: stable draft vs. experimental RFC? Chris Newman: Protocol draft seems fine. Reputation is uncertain, but reputation is not in the protocol spec. Operational questions aren't in the protocol spec. Protocol is ready for Proposed Standard. Dave: Yes, the spec is *probably* fine, but might not be since it's a new trust model and we don't know what the operational dynamics are. As we get experience we may find that we need to change stuff. Barry: Does realtime make this different from certs? Dave: certs are typically signed statically. Eric Rescorla: How is sequential signing different? Rich Salz: How can the signatures get out of order? Barry: The point is that it's a dependent chain, with each sig dependent upon the earlier. Bron: What happens if there's a DNS failure in the middle of the chain? Kurt: Typically back to whoever it came from. Bron: Config failures cause failures in the wrong place, such as unsubscribing someone. Dave: DKIM as model works in some contexts but fragile within an enterprise, example of sequential fragility. Alexey: Pick one, no strong opinion. Can ask ops and dns directorates if they see problems. Murray/Kurt: If it's experimental make it clear what the experiment is. Dave: When there's comfort to write operational advice document it's no longer an experiment. Decision: We will continue discussing on the list, and will not hold up WGLC for this issue. We need to have a working group decision by the time we request publication (after WGLC). 5. Handling enhanced reporting - What should be reported in a DMARC report when ARC is involved? Kurt: A-R was for humans, AAR is for machines. Selector and source IP useful for sender troubleshooting, so adding them to AAR is useful. Inline JSON in a comment? Does each step send reports? Probably. Seth: Need to get what's transmitted and how into current spec, update to DMARC can wait. 7. DMARC "usage" document -- status and what to do Tim: Summary posted. Publish draft, gather experience, guide is useful to codify experience. Small set of people to contribute to usage guide, but is there enough interest to do it now? If not, could do it elsewhere later. Barry: The objection is that as there are already lots of DMARC usage guides, why do another one? Kurt: Are we looking for anecdotal reports? Does that provide value? Jim Fenton: Do we need an ARC usage document instead? Barry: "Instead", or in addition, or combined... Alexey: Need not be RFC, could be a wiki or the like. Barry: Exactly. Tim, are you willing to continue work on this with the understanding that the working group might later decide not to publish it? Tim: Yes. Decision: Tim will continue work on the DMARC usage document, and after we see where it goes, the working group will decide whether to publish it. 8. AOB Kurt: A charter goal was to get DMARC to standards track. When we finish ARC, what do we do next? Barry: I believe we need something in DMARC to address the breakage problem before going standards track. Maybe not realistic but think about it as a challenge. Murray: We can start collecting issues in the tracker now, and don't have to wait.