Minutes IETF101: dmarc
minutes-101-dmarc-01

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