Re: [dmarc-ietf] Charter improvements

[Franck Martin <[e-mail]>]

On Jul 16, 2013, at 8:39 AM, J. Trent Adams <[e-mail]> wrote:

> 
> Thanks, everyone, for their input on this thread (and to John for the
> pointer how to get back to land when I blundered into the wrong stream).
> Editing the proposed charter is a lot easier with this feedback.
> 
> From what I can tell, the most important question needing to be answered
> is whether or not revising the base DMARC specification is within scope
> of the proposed work group. Following Russ's guidance, it seems that we
> should start from the assumption that it's not in scope for now given
> the fact that it's being sponsored by an AD as an Individual Submission.
> 
> Regardless of whether that's the right path, or not, let's explore it as
> an option and see how the rest of the items identified in the proposed
> charter play out. Then we can leverage the outcome of the conversation
> to potentially revisit the fate of the base specification itself.
> 
> Given that guidance, here're the most obvious (and noncontroversial?)
> items needing to be done to shore up the proposed charter:
> 
> * Correct the text regarding the current path of the specification.
> * Tone down the "marketing puffery".
> * Clarify how to address "backward compatibility" with the installed base.
> 
> I've already updated the description of the current path of the base
> specification from "Independent Submission" to "Individual Submission",
> so that's one down. I'll pull out my red pen on the other two topics and
> see if I can make them more reasonable.
> 
> Skipping ahead. . . here're the items that have previously been proposed
> as worth exploring in the setting of an IETF work group:
> 
> -----
> * a mechanism for determining the organizational domain name based on an
> arbitrary fully-qualified hostname
> -----
> 
> If I'm not mistaken, the Apps Area WG has already expressed an interest
> in this work. In that case, I believe that this WG would only need to
> track that effort and ensure that its work addresses the use cases
> required to support DMARC.
> 
> QUESTION: Given that it's an important topic, and there's no guarantee
> that the other effort will result in an applicable solution, would it
> still be reasonable to include a mention of this as worth exploration?
> If so, it'd probably make sense to reference the other work as a
> starting point to clarify we're not planning to spin up a competing
> solution.
> 
Isn't it the place where the BCP could answer that question, by giving guidance on how to do it pending a standard?


> -----
> * a mechanism for detecting abuse involving the <display-name> portion
> of the RFC5322.From field
> -----
> 
> This is an interesting item in that there have been some proposals from
> contributors to the base DMARC specification to address this. The
> proposals, as you can see, didn't make it through to a consensus and it
> was suggested that they be brought to the broader community for
> consideration. It's highly likely that through the WG process we're able
> to identify a means by which this issue can be addressed.
> 
> QUESTION: Does it make sense for this proposed WG to explore how the
> base specification can be extended to apply the same level of
> "identifier alignment" to the <display-name> as is helping defend the
> <address-spec>?
> 

why not

> -----
> * a mechanism for mitigating the effect of failures of DMARC policy when
> a message transits a mailing list
> -----
> 
> I recognize that there's definitely a counter-pressure against including
> this topic as it seems to be a potentially quixotic quest. That being
> said, even if we don't find the perfect solution, it does seem
> reasonable to believe there is a way to provide something more than
> nothing that does help in some meaningful way. I'm not presupposing a
> solution, just that there have been a few possible options discussed at
> the edges which are likely to be worth more rigorous exploration.
> 
> QUESTION: Is there value in a WG such as this exploring possible
> solutions to this issue and developing guidance that would potentially
> help improve the utility of the base DMARC specification?
> 

This is a hot topic, and it smells a lot like qmail, but people will want to protect any domain. It seems rather to me the question is once a domain has p=reject what the miscreants do? Where the next protection should be put on? I'm not saying bad stuff happen through mailing lists, I'm saying bad stuff will happen to other domains (and there is a whole bunch coming up). It seems also to me we have the problem of defining what is a mailing list, in a similar way what is an organizational domain. Everyone knows when they see one, but not can define it in a machine parseable way.


> -----
> * support for the notion of transitive trust (i.e., "host X trusted the
> sender of this message, and I trust X, so you should too")
> -----
> 
> I see this as similar to the above, but potentially more broadly
> applicable. One tweak I'd offer would be to replace ", so you should
> too" with something like ", so you could choose to as well".
> 
> QUESTION: Is there value in a WG such as this exploring possible
> solutions to this issue and developing guidance that would potentially
> help improve the utility of the base DMARC specification?
> 

is there transitive trust defined in other IETF documents?

> -----
> * more robust transport of reports
> -----
> 
> After over a year of deployment, and the rise in support services
> handling reports, many folks have suggested that it would be worth
> exploring how to offer additional optional means of transport for
> reports. The base DMARC specification provides for this, but it is an
> area that was left to be extended by a group such as this.
> 
> QUESTION: Is this an area of exploration that is of enough interest to
> include in the charter for this proposed work group?
> 
> Beyond those, the topics in the proposed "Using DMARC" document have
> already proven useful in clarifying some options that aren't typically
> included in a base specification. For example, here a few items that may
> benefit from being specifically called out in the charter as worth
> exploring:
> 
> * Identifier alignment configuration options
> * Implementation decisions regarding "pct"
> * Determining effective RUA sending frequency
> * Leveraging policy caching
> * Various options for integrating within an existing flow
> * Defining a useful, common set of RUA reporting options
> * When and how to use local policy override options

A lot of it is gained thru operational experience, common sense and level of threat. A BCP to help implementation whould answer a lot of these questions

> 
> QUESTION: Do any items on this list seem to be worth specifically adding
> to the proposed charter as examples of the type of work that would be
> useful?
> 
> Finally, this list of potential work items was developed a while ago,
> and it's likely additional possible areas of exploration have surfaced
> since then. Are there any other substantive items that would be worth
> adding to the list? Keeping in mind, of course, that our first cut will
> be to assume that the base specification isn't in scope for now.
> 
> Once the dust settles a bit around these items, I'll take another whack
> at the charter text to at least get it stable for now. Then we can
> bubble up the bigger question and see if we can tackle that given the
> input I've seen recently on other threads.
> 
I have the feeling that DMARC brings the subject of domain reputation and becoming stricter in what we receive. draft-ietf-appsawg-malformed-mail is a step in that direction, but may be we need to examine the problem more broadly of cousin domains and other forms of non direct domain spoofing. What are the tools we have today to handle them?


> Thanks again,
> Trent
>