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 <barryle...@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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc