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

Thanks to all, especially note takers

One request to the chairs - can you upload the slide deck into the
datatracker also?

thanks
tim

On Thu, May 27, 2021 at 3:55 PM Barry Leiba <barryleiba@computer.org> wrote:

> The notes are in the etherpad and also uploaded to the meeting
> materials page here:
> https://datatracker.ietf.org/meeting/interim-2021-dmarc-01/session/dmarc
>
> 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.
>
> Barry
>
> -------------------------------------------------
> 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:
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/
>
>
> Agenda:
> 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
> question...
>     * 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
> issue
>     * 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
> discussion
> * 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
> -------------------------------------------------
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>