I don't have a summary. To the extent I mentioned any specific proposal it was meant to be merely exemplary. The point, is to come up with a framework to discuss solution utility. Because there is a certain breadth of deployment needed for interoperability for some solutions, I don't think Pareto analysis is useful at all.
We've spent a lot of time going around in circles about various proposals and so I'm trying to come up with a useful way for us to focus. It doesn't eliminate the need to make sure any method we pursue works and is secure, it's just a way to see what clears the minimum threshold for deployability to provide a potential for interoperability. Your mail is mostly arguing about specifics of different solutions. That means we're not at all on the same page. I'm attempting a step back to define a framework we can use to move the group forward. Please look at it at that level and take a step back both from the well known history and the particular solutions you like or don't like. Scott K On Thursday, April 16, 2015 01:03:20 PM Hector Santos wrote: > Scott, > > what is your summary with all this? > > We probably should understand optimization concepts such as Pareto > Optimality and Query Dissemination. Both are applicable here as well. > > I've actually have two receivers; one for the mediator and one for the > end-users. The problem was that Levine did not want the mediator > receivers to support policy. Hence ADSP got no support by MLM receivers > (except for us, but we didn't flip the rejection switch, just recorded > results). What Levine forgot was the user receivers, and that is what > DMARC forgot too. Overall, they presumed no one will take it serious and > honor it, including controlling the MLM entry points. > > Well. It did. > > We got many IETF-MAN-YEARS of engineering into all this and the policy > lookup was the method ultimately devised as the baseline. While it was > confused with mandates to limit the business damage to the resigner market, > and a focus to kill policy methods all together, it never removed the need > to get 3rd authorization from the ADID. > > Blind resigners was a security threat. DKIM could not separate the purported > author from the signature and signer. The 5322.From is required. If it > wasn't, we would then have a different security model. From all historical > angles, from rewrites is simply not a good idea to crack open that door. > It changes everything and makes the entire discussions moot. As mentioned > before, a rewrite is most certainly IETF Appeal sensitive. Just saying. > > RFC work was done for threats, requirements and overall the DKIM > architecture and using 1st and 3rd party policy framework is a result and > consistent with all the IETF-MAN-YEARS put into this work. We were > complaining about the actually record and query method and possible > management complexity. Not so much the registration part of it because > that can also be learned over time. This work is still relevant and even > more so today because the mindset has changed to enable policy (via DMARC). > We simply did not have this before with ADSP. So DMARC has changed the > game. > > The in-band is fine but it's weaker and more expensive to implement, and the > registration is still required by the organizations still interested in > keeping with a higher level of DKIM security strength a policy framework > provides. Let's not assume that given no other design option, sites will > just blindly sign all mail. Given no other choice, who knows, you might > force sites to re-invest in their DKIM engine to do this double signing > and also do the policy level verification, > > Also, keep in mind, the failures points of the proposal too. That's very > important here. Are we ready to do the MUST/SHOULD for negative > classification (reject/discard/quarantine) when the detectable @fs= > protocol failures exist? Remember, it's not just about looking for the > good, but filtering the failures from the stream, and we can't once again > get the disillusionment that no one will honor rejection because the two > receivers are also using query dissemination methods to minimize connection > abuse issues. > > Look, supposedly opendkim has support for ADSP/ATPS. A simple change to > piggy back off the DMARC record itself with the renewed interest for policy > now, we can better measure the level of support and also provide the > opportunity for sites to do registration R&D. > > -- > Hector Santos > http://www.santronics.com > > > On Apr 16, 2015, at 10:11 AM, Scott Kitterman <skl...@kitterman.com> > > wrote: > > > > I will probably regret this, but since people are throwing around things > > like Pareto to argue in favor or against specific solution areas, I > > thought it might be useful to take a step back and look at what might > > make a solution (or set of solutions) useful to pursue. > > > > For indirect mail flows like mailing lists, there are three actors > > involved: > > > > 1. Originator > > 2. Mediator > > 3. Receiver > > > > For the purposes of this discussion I'll further categorize the entities > > involved as big and small (yes, it's way more complex than that, but I > > think that's sufficient). > > > > That leads to six combinations: Originator/Big, Originator/Small, > > Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small. > > > > There have been solutions proposed that only require changes for one of > > the > > three above, that require changes at two of the above, and that require > > changes at all three. > > > > Two examples of solutions that require changes only for one actor are > > configuring mailing lists not to make changes that break DKIM signatures > > and mailing lists rewriting the body From to a local value. While both > > of those have drawbacks, from a utility analysis perspective, I think > > they are useful to include in the family of solutions to the indirect > > mail flow problems caused by DMARC. > > > > Rationale: They can be deployed by mediators both big and small with no > > further coordination with other actors. For mediators that choose to go > > down this path and accept the downsides of these approaches, they can > > solve the indirect mail flow problem. > > > > Another example of a potential solution is receivers amalgamating data > > from > > across their user base to identify forwarders and utilize a local policy > > override to not reject DMARC fail messages assessed to be sent via an > > indirect mail flow. This is supported by the DMARC specification, but > > it's not something that Receiver/Small is going to be able to do. It's > > only really useful for Receiver/Big. It should be included in the family > > of solutions, but it could not be said to 'solve' the indirect mail flow > > problem since it doesn't scale down. > > > > While none of these three solutions are complete, they are complete at > > least for those entities willing and able to deploy them. > > > > Once a solution requires changes from multiple actors, the assessment is > > more complex. If a solution requires (as an example) both sender and > > receiver changes to work, then if it only works for small entities, then > > I don't think it has utility. Since Big sends to Small and Small sends > > to Big, any solution that affects multiple types of actors needs to work > > for both Big and Small, otherwise if a Small only solution is deployed it > > will fail when Small sends to Big. Conversely, if a Big only solution is > > deployed, it will fail when Big sends to Small. > > > > This type of assessment is why I was attracted to John Levine's fs= > > proposal. While it is inherently very complex to deploy (it definitely > > requires sender and receiver changes and for some indirect mail flows > > [those that strip signatures today]), there is nothing inherently Big or > > Small about it. I think it has other problems that may or may not be > > resolvable, but from a solution space coverage perspective it is > > attractive. > > > > For the complex solution set that covers multiple actors, I think we have > > to have a single solution to propose. If we have multiple, multiple > > actor solutions, then interoperability in this space gets much more > > complex. For single actor solutions, any solution that works and can be > > deployed helps interoperability because if any actor deploys it, the > > breakage is reduced. For multi-actor solutions, adding additional > > solutions probably reduces interoperability since in any given mail > > transaction (Originator -> Mediator -> > >> Receiver) all three have to have the same solution deployed. If the > > > > Originator and Receiver have deployed three part solution #1 and the > > Mediator has deployed three part solution #2, then both solutions fail. > > It's the same as having done nothing. > > > > In terms of what makes sense to specify in the output of the working > > group, I think we should be willing to accept as many single actor > > solutions as we discover and have energy to document. They are always > > good. None of these solutions is free of side effects and actors should > > be free to pick their poison as long as it doesn't break things > > elsewhere. > > > > For multi-entity solutions, I think we should be more constrained. I > > think > > any multi-actor solution has to work for both Big and Small actors or else > > there is no interoperability. I think at most one three actor > > modification > > solution ought to be included. I think there is possibly room for > > solutions that relate only to two actors in addition. We can't afford, > > both in terms of working group time and energy and in eventual > > interoperability to have a lot of choices in this more complex space. > > > > Note: This is not intended to say anything is in or out, just to give a > > framework for the discussion. > > > > Scott K > > > > _______________________________________________ > > 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
