[dmarc-ietf] Notes from DMARC interim teleconference, 27 May 2021

Barry Leiba <barryleiba@computer.org> Thu, 27 May 2021 19:55 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8BA483A0C35 for <dmarc@ietfa.amsl.com>; Thu, 27 May 2021 12:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.402
X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id RAcfx7AgUV_C for <dmarc@ietfa.amsl.com>; Thu, 27 May 2021 12:55:22 -0700 (PDT)
Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26153A0C29 for <dmarc@ietf.org>; Thu, 27 May 2021 12:55:22 -0700 (PDT)
Received: by mail-lf1-f54.google.com with SMTP id b26so1848263lfq.4 for <dmarc@ietf.org>; Thu, 27 May 2021 12:55:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=0bAYrG8s6aJbBZzYx6tgjRAqHMM3EQieLDELVxUugFg=; b=hBXpTQflLIV/VNdBohQvhnE/VINjRhUoL4eQ7YoCO19Vkj3EMsiTApW8N26wX1fAvL lsluuMVr8yA0+lyhGBlWah4jgHpYXwLPdVh5C4sK83TxN86osAeTWTbfFMxtC6B3l1zT FCgOMkmgdilRfyDroc/R8AFJsxhrIxbSktVxTWPn6EB+IkxTTkv0lmXeCjugy8IDQhxd cOUJq7KHSf34qjSTMGqJGbN0OCjuTF030aIsTFf0OTB7lvs92kxZODyeTW0sLGfmHxCh hcJ3sf+Joo+31OuU+pjxAn9p4Jy5mjZVpYHcPDYy/K5YQct+UrImZ6Bz21lFzYrVKGyy jXQw==
X-Gm-Message-State: AOAM531PCg2VxZpZmr4AbVBQpX+ZMMJkIQ3KF9hZbBmUnpqkdKznNIkD DU2tWlP1JmVc2CBsfGq4zrLYqpi4QZpOZEqj182cpfC9FM4WOg==
X-Google-Smtp-Source: ABdhPJwiolLxR+QOO2AkIG79crO7NE16PTYc2dEOfk/i9V5edHvOHT1LpsOEfIe3tnAPVgvUclIiAbdvWzV5Tqr3LFc=
X-Received: by 2002:ac2:4a89:: with SMTP id l9mr3216990lfp.643.1622145319906; Thu, 27 May 2021 12:55:19 -0700 (PDT)
MIME-Version: 1.0
From: Barry Leiba <barryleiba@computer.org>
Date: Thu, 27 May 2021 15:55:08 -0400
Message-ID: <CALaySJLBSNorzOW4QqokDDCN6wGqYM=eyTCmrf2XGONpK+OGfg@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/PPskhJKs-cvXJpjzh-UiJQ9ba4M>
Subject: [dmarc-ietf] Notes from DMARC interim teleconference, 27 May 2021
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2021 19:55:28 -0000

The notes are in the etherpad and also uploaded to the meeting
materials page here:

For convenience, I'll paste the content below as well.

Thanks to everyone who participated in a very productive meeting, and
thanks especially to Kurt and Todd for taking detailed notes.


DMARC working group interim meeting
16:00-18:00 UTC, 27 March 2021

The purpose of the meeting will be
to discuss the design team recommendations and remaining open issues
in the following documents:

1. Introduction and agenda bashing
2. Discussion of draft-ietf-dmarc-dmarcbis
* [Ticket 4](https://trac.ietf.org/trac/dmarc/ticket/4) - Definition of "fo" tag
* [Ticket 47](https://trac.ietf.org/trac/dmarc/ticket/47) - Remove "pct" tag
* [Ticket 50](https://trac.ietf.org/trac/dmarc/ticket/50) - Remove "ri" tag
* [Ticket 52](https://trac.ietf.org/trac/dmarc/ticket/52) - Remove
strict alignment and "adkim" and "aspf" tags
* [Ticket 53](https://trac.ietf.org/trac/dmarc/ticket/53) - Remove
message size chunking
* [Ticket 54](https://trac.ietf.org/trac/dmarc/ticket/54) - Remove
limit on report recipients
* [Ticket 82](https://trac.ietf.org/trac/dmarc/ticket/82) - Deprecate "rf" tag
3. Discussion of draft-ietf-dmarc-aggregate-reporting
4. What would we have to do in order to bring this project (DMARCbis)
to closure?
   * and possible timeline
5. AOB

Note-takers (https://codimd.ietf.org/notes-ietf-interim-2021-dmarc-01-dmarc):
1. Kurt Andersen
2. Todd Herr

# Notes:
## Introduction and agenda bashing
[technical problems with screen share]
* high-level review of current situation (see slide)
* would like to have regular interim meetings to drive tickets to closure
  * all items will be confirmed on the list - focus on the text and tickets
* review of charter constraints - operational experience

## Discussion of draft-ietf-dmarc-dmarcbis
* [Ticket 4](https://trac.ietf.org/trac/dmarc/ticket/4) - Definition of "fo" tag
    * clarify the tag value to eliminate non-sensical combinations
(see proposed text)
    * John Levine: seems reasonable
    * Autumn: in favor
    * Kurt: what about handling illegal combinations?
    * Alex: maybe senders will be more careful if they know what will happen
    * John L: if they don't follow the spec, it should be undefined
    * Kurt: should this just invalidate failure reporting?
    * Michael: at this point, most failure reports are only being done
within the scope of contractual arrangements
    * Seth: concurs, but don't just hedge on the basis of failure
reports are "rare"
    * John L: don't worry about what happens if someone does the record wrong
    * Dave C: simplifies the spec if we only focus on what is correct
    * Michael: agrees about the spec only talking about happy path
    * Seth: focus on these tags, have a separate ticket to rationalize
any changes to tags
    * Sense of the room: in favor

* [Ticket 47](https://trac.ietf.org/trac/dmarc/ticket/47) - Remove "pct" tag
    * see stats on the slide and in the ticket for usage
    * Autumn: it is being used outside of the intent in order to drive
reporting conformance; is there another way to get that done? "pct=0"
is really the only meaningful flag
    * Steve: very important for onboarding - supposed to be temporary,
those use cases would not always be visible after 6-18 months
        * business decision makers need to feel like they are in control
        * has some different numbers based on Farsight data in 2021Q1
but needs to do further analysis
            * 747,641 out of 2.9M records
            * 672,640 are at 100
            * 8,078 are at 0
            * 66,923 are not 0 or 100
    * Michael: not a fan, but don't see a compelling reason to remove
    * Seth (not as chair): the way it is defined today is highly
problematic - either fix or remove
        * only sees 3 meaningful levels for ramping but may interact
with SP/NP tags
        * what steps are really needed
        * consider discussing in the next interim meeting based on
some proposed text changes
    * Autumn: people report that they don't understand how it would work too
        * who / how many are using something <100 and how long will
they take to get to 100
    * Alex: what about removing the extremes (0,100)?
    * Seth (as chair): defer to future meeting based on specific text
    * Michael: can we get rough consensus on this specific question?
    * Todd: there was an issue with Google groups at one point in time
in order to get agg reports
    * John L: also used '0' to test mailing list hacks with rewriting
    * Consensus: keep the tag but rewrite (Todd will tackle)

* [Ticket 50](https://trac.ietf.org/trac/dmarc/ticket/50) - Remove "ri" tag
    * Not currently being honored - text allows
    * Options: keep, deprecate
    * Steve: Quick pull from Farsight 1Q2021 data again:
        * 391,861 policies with ri= tag
        * 273,098 ri=86,400
        * 102,344 ri=3600
        * 4,075 ri=84600
    * Ale: The report producer is responsible to implement the "ri"
timing. It is also connected to the report size chunking (as a
function of time). Have not seen data about the sizing/timing
    * Alex: not aware of any reporter who honors the tag
    * Alex: also not sure what the interaction with the chunking size setting
    * Seth: chunking size seems to generally break reports as a whole
    * Seth: some reporters charge based on report frequency (but seems
like a non-IETF consideration)
    * Kurt: suggests removal
    * Seth: the result of this should not affect how DMARC works
    * Michael: maybe deprecated is the right approach
    * Todd: some problem with purists who harp on "you're not doing it right"
    * Seth: when moving to proposed standard, do we have to worry
about the past (informational)?
    * Dave: strong "yes" to removal; don't use "deprecated"
    * Michael: there is a fair amount of existing code in production?
Will any of that be changed?
    * Seth: should not make any difference
    * Dave: maybe some specific text pointing back to the
informational version would be appropriate
    * Michael: sounds good
    * Dave: maybe in the intro or background
    * Steve: A supporting document can have detail/history about
"things you might find"
    * Tim: notes in chat that IANA registry cites "ri" - will have to
be cleaned out
    * Consensus: remove the tag, update the registry

* [Ticket 52](https://trac.ietf.org/trac/dmarc/ticket/52) - Remove
strict alignment and "adkim" and "aspf" tags
    * Todd (from slide): Usage of these tags is in the 2-5% range "s" value
    * Seth: should this be rolled into the "ratchet"/onboarding conversation?
    * Autumn: agree that basically no one uses it, but some banks
think that it is valueable
        * some of the people who use it are confused about what it
really delivers
        * but are highly committed to being "strict"
    * Dave: only supporting relaxed might be better at setting expectations
    * Seth (not chair): should get rid of this, but might trigger
interop justification
    * Alex: some entities were going to be enforcing strict alignment
regardless of the spec and published records
    * Dave: might be worth considering special communities who might
want to extend the core spec; don't keep these pieces in the core
spec; move it to an ancillary spec
    * Michael: does having it in, break interop?
    * Dave: it raises unrealistic expectations
    * Seth: it confuses *everyone* - does harm to adoption of the spec
    * Michael: most people don't even bother to read the spec
    * Seth: what value does this actually deliver?
    * Michael: it allows people to segregate different mail streams
into subdomain streams
    * Seth: sounds like we need some more data
    * Consensus: table this for further investigation and later discussion

* [Ticket 53](https://trac.ietf.org/trac/dmarc/ticket/53) - Remove
message size chunking
    * Todd (from slide): <2.3% usage across records
    * Seth: some major report providers not only ignore this, but use
it as an invalidation for the DMARC record as a whole
    * Ale: if you pass this limit, what "should" you do?
    * Seth (not chair): much easier to remove than worry about the edge case
    * Michael: this was put in to deal with the hypothetical risk of
too large reports
    * Seth: has not turned out to be a real problem
    * Alex: kill it
        * +1 - Kurt, Michael, Seth
    * Consensus: remove it and update registry

* [Ticket 54](https://trac.ietf.org/trac/dmarc/ticket/54) - Remove
limit on report recipients
    * No known limits currently enforced
    * Seth (as report receiver): what happens if there are "too" many
- related to mandated centralized reporting - never seen this be an
    * Autumn: curious to know how many people use large numbers; some
use distribution lists
    * Steve: See aliases/DLs used to mask report processor as well as
numbers. I'll try to get data for number of mailto: URIs.
    * Seth: Limit is intrinsic to the DNS record size
    * Hypothetical risk earlier on had to do with indirect mail bombing.
    * Kurt: should say they need to handle >1
    * Seth: why not avoid the normative language
    * Kurt: adjust proposed language to use "SHOULD" and remove "in the order"
    * Autumn: if someone does specify 15 or 50 addresses, then systems
will probably treat it as a misconfig
    * Seth: what if a reporter screws it up? don't worry about that
    * Michael: agrees with Kurt's changes
    * Consensus: proposed language as modified

* [Ticket 82](https://trac.ietf.org/trac/dmarc/ticket/82) - Deprecate "rf" tag
    * There is only one format, and rf is not widely supported, is
there any value in keeping it?
    * Seth: consider proposals coming from Steve/Ale if no alternate
versions, then drop the tag
    * Alex: what about X-ARF format?
    * John L: hard to imagine anyone doing anything more - suggests
removing the rf tag
    * Autumn: if something else is put forward, would it necessarily
be a different format?
    *  Dave: simple rule, if there's a clear need for variability,
support it. If it's hypothetical for future need, they tend not to
work out. Adds complexity, not utility.
    *  Seth: Expectation was that there would be different ways in
future. That hasn't panned out.
    *  Mike: At the time, we didn't know, so we put the flexibility
in. I get the argument for simplicity, but removing something like
this sets a higher barrier if there's a need in future.
    *  Seth: We can add it in future if that's the case
    *  Mike: More than just adding to the registry, you'd need to
update the standard.
    * Dave: is the doc processing the most important or is it the
systems implementation cost?
        *  making a standard based on "what if" is a really bad idea -
not-useful complexity
        * makes a messier spec with problems
    * Seth: getting rid of the "whatifs" from the early work is where
we will get real value
    * Michael: in the wild, we do see people stripping stuff from ARF
reports (based on GDPR); how do we provide a standard way that will be
endorsed by the EU privacy folks?
        * how do you get meaningful, privacy-preserving reports that are usable?
    * Dave: this is all theoretical
    * Michael: this is not just a theoretical issue
    * Dave: the issue is real, the actions are theoretical
    * Seth (as chair): seems like consensus to remove it with future
potential concern
        * maybe move this tag into the failure report spec, out of the core
    * Michael: OK
    * Steve: still available if the failure report work finds a need?
        * Seth: yes, but not in core spec

## Discussion of draft-ietf-dmarc-aggregate-reporting
* Alex: do we need to preserve compatibility with 7489 report processing?
    * do we need a method for the domain owner to specify version of
report to be created?
* Seth: over time, the report has already varied; first let's design
what we *want* to create, then discuss details and implications
* Alex: is it excessive to *require* the version specifier to be part
of the report?
* Seth: start with what we agree to be desired
* Alex: sounds like "keep going, change as needed, discuss"
* Seth: any other concerns with this approach?
    * no responses

## Reporting Questions (Alex)
* Alex: there have been some asks for additional information
    * can a standards track doc normatively refer to an experimental?
        * reference yes; rely/depend on requires additional approval -
try to avoid
    * Suggested core spec with extensions to cover more information
* Barry: that should be easy - can be done with informative reference
* Murray: could also republish the other specs as PS but that
stretches out the timeline
* Alex: how to best refer to the known extensions?
* Barry: just refer to them informationally (non normative)
* Dave: question of directionality - having the core spec refer to
extensions is not a good approach; the extensions should refer back to
the core for referential integrity
* Seth: the generic reporting mechanism in the core spec should define
the framework for the information, the extensions provide the details
on how said framework gets filled in for the details of the protocol
* Ale: makes sense, can do a generic extension
* Alex: wants to be clear - other auth methods should be entirely part
of the extensions
[Seth had to leave]
* Kurt: would like to see details
* Alex: trying to avoid breaking the base part of the report
* Michael: as long as we provide for extensions, then it is just
defined within the XML
* Alex: any XSD definition could be OK for an extension
* Kurt: seems like some data might fit better at the row level, some separate
* Ale: can we have a registry of extensions?
* Alex: would like to be able to give receivers a chance to provide other data
* Michael: creating a general reporting tool seems like it is too large in scope
* Alex: is there value in making this super general
* Michael: various providers have various other data available, narrow
is better, keep close ties to auth
* Kurt: seems like a repeat of the general/overly complex/hypothetical
* Laura: if you give people a chance to do this, then they probably
will - even if it isn't useful
    * problems with standards "semi-compliance" by big providers will
probably lead to complications handling the reports
* Alex: if we limit this to official IETF extensions, does that help?
* Laura: these reports are about auth failures, not general email
stuff; for that, maybe abuse X-ARF
* Laura: don't give them free-form extension capabilites
* Laura: most senders rely on report processors to consume the reports
and make them meaningful; the extra details will probably not get back
to the senders
* Alex: will start a new thread to the list (Next week)
* Steve: seems like there are deeper existential issues to be resolved

## Failure reporting (Steve)
* [Ticket 55] - may have been addressed
* [Ticket 28] - report driven mail loops - thought it was closed, but
then looked like Murray re-opened it
* Ale: liked the proposal from John L (on the list)
* Steve: will review the mail thread
* John L: mail loop thing was deep in the "don't do that" category -
out of scope to solve in the spec

## What would we have to do in order to bring this project (DMARCbis)
to closure? and possible timeline
Barry: was this productive? Should we do more?
Generally: yes
Dave: need to beware of having sync meetings become primary - only use
interims for complicated/intractable issues
Barry: the chairs are aware and things will be kept in line
Michael: this does keep things moving forward
Barry: need to make sure that we are actually having discussions on
the mailing list and using the teleconferences to follow up on that,
not just using the mailing list to rubber-stamp the teleconferences

## AOB
* Next steps - Todd will open individual threads on the ML about each
item for general consensus
* Murray - congratulations on getting PSD published
    * Is anyone tracking the progress of the "experiments"?
    * Having data will really help down the road

Attendees (name, affiliation):
1. Barry Leiba, Futurewei Technologies, chair
2. Seth Blank, Valimail, chair
3. Murray Kucherawy, Facebook, AD
4. Todd Herr, Valimail, DMARCbis editor
5. Autumn Tyr-Salvia, Agari
6. Kurt Andersen, Blameless
7. Tim Wicinski
8. Alex Brotman, Comcast
9. Laura Atkins, Word to the Wise
10. John Levine, Taughannock
11. Michael Hammer, AugTagger, Inc.
12. Alessandro Vesely, tana
13. Dave Crocker, Brandenberg InternetWorking
14. Matthäus Wander, bsi.bund.de
15. Doug Foster
16. Michael Richardson, Sandelman Software Works Inc
17. Steve Jones, DMARC.org