Minutes IETF99: dmarc
minutes-99-dmarc-02

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 <from> addresses, start
experimenting in September.  Different <from> 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.