IETF101 - DMARC-WG Notes

Begin at 17:42

Agenda
17:40  < 5 min  Introduction and administration
17:45  15 min  ARC protocol status and remaining document issues
18:00  15 min  Status of other documents and issue discussion
       draft-ietf-dmarc-arc-usage Recommended Usage of ARC
       draft-ietf-dmarc-arc-multi Using Multiple Signing Algorithms with ARC
       draft-ietf-dmarc-rfc7601bis Updates to Authentication-Results
18:15  25 min  Next steps, including:

       path toward a Proposed Standard version of DMARC

       protecting against abuse of last-level public domains (org-1) (such as gov.uk) and first-level NXDOMAIN org domains (junk.gov.uk)

       diagnostic report that would have some additional information (such as sending address) and URLs without going quite as far as a forensic report - something between the aggregate and forensic levels

       draft-akagiri-dmarc-virtual-verification DMARC verification without record definitions


Protocol spec:
 - New version of ARC protocol published Sunday evening
 - Tickets have been resolved, so please check the new version
 - Structural: suggestion to pull reporting into separate document
   - Should we?
   - Because it’s interim, maybe easier to rev.
   - decision: keep it in one document for the experimental version
   - revisit the issue when we go to standards track
 - Explicit dependency on 7601bis
 - Close to ready for WGLC; looking a next revision by mid-April

Usage doc: save for after experimental experience?
 - post-experiment seems right
 - make sure we get data from the experiment

Multiple signing algorithms doc:
 - impending DCRUP release of EC algorithms
 - not expecting this to be a live issue for a while yet
 - also slight incompatibility with current code
 - ship experiment now, add this separately

7601bis: nothing outstanding; updates; WGLC coming soon
 - Have added updates related to DCRUP and EAI, while we have it open

Next steps:

How do we get to a standards track version of DMARC?
 - Do we need to wait for ARC results before getting to PS?
 - Can work on a revised DMARC spec in parallel, but need to make sure ARC really is effective
 - The wiki has a list of DMARC issues that will need to be resolved
 - Dave suggests documenting DMARC experience, issues, projected changes that are believed sufficient to justify standardization. Get wg consensus on the that. Circulate it to the IETF and the IESG.
 - Bron notes that we don’t have any experience yet of people trying to abuse ARC; they likely will.
 - Issues with forwarding calendar invitations and DMARC breakage. THe situation is related to that of non-breaking forwarders, and/or mailing lists, but has some differences.
 - Perhaps do significant document restructuring to separate actions by senders/receivers/reporting.
 - Keep a running list of issues in the tracker.

Protecting org-minus-1 domains:
 - Using public suffix list now; this brings the DBOUND issue back
 - We should consider this issue as we do a standards track DMARC spec

Should we have an intermediate-level report option, something in between aggregate and forensic?
 - Maybe make it clear what freedom is available to report generators
 - Tim will propose text & specifics as to what to include
 - Specifics needed about what would be proposed in the semi-aggregate

"Virtual DMARC" draft-akagiri-dmarc-virtual-verification
 - DMARC “pass” evaluation, even without published DMARC records
 - call this “virtual DMARC”
 - Barry “don’t get it” - receivers already check SPF and DKIM, so what value does this add?
 - Neil agrees, notes that all the info is already available in A-R or in the headers themselves
 - Barry doesn’t want to put WG resource into this unless there's clear benefit
 - Authors will consider these questions and Will follow up on the list

Adjourn at 18:40