Re: [dmarc-ietf] Updated mandatory tag/conditional signature draft

[Douglas Otis <[e-mail]>]

On 4/14/15 8:30 AM, Scott Kitterman wrote:
> On Tuesday, April 14, 2015 11:11:00 AM Hector Santos wrote:
>> On 4/14/2015 10:07 AM, Scott Kitterman wrote:>
>>
>>> If I misunderstood the proposal and it requires someone to be keeping a
>>> list of mailing lists used (either globally or by individual users), then
>>> I think this is not a good idea at all.  I don't think any
>>> tracking/whitelisting design is going to succeed at scale.
>>>
>>> My view is that either we find a reasonable way to make this idea work
>>> without a list of mailing lists or we toss it on the pile of things that
>>> won't work.
>> Which is why the simple DNS lookup remains to be the ideal baseline
>> and natural part of the generic DSAP (DKIM Signature Authorization
>> Protocol) design. You need to cover all process model boundary
>> conditions which include 1st and 3rd party mail streams. If you
>> exclude one, its incomplete.
>>
>> The Publishing and "Registration" problem has been overblown.
>> Registration basically means to find the domains (your network of
>> signers) to publish.   The latter is a business problem, not a IETF
>> technical protocol problem.  If we had used a "registration/scale
>> problem" philosophy for other early IETF protocols, they were have
>> never been completed as well and gotten to where we are at now.   SPF
>> has this same scale concern, and it still currently an extremely high
>> wasteful DNS calling authorization check method for senders.  The
>> larger domains also had to "find" their network to register them as
>> SPF machines.  So this is not any different.
>>
>> The DNS "Lookup" algorithm has been the basic backbone idea since
>> 2003, since LMAP ideas, since DNSRBL, since MAPS, well since forever,
>> etc, the idea of "Looking up" an verified, integrity authenticated id
>> for authorization, either its for bad or good, it became fashionable
>> and an acceptable concept overtime by the DNS community. They bemoaned
>> it but the DNS TXT-BASED applications was on the raise as an fast
>> entry method to explore many new authorization ideas.
>>
>> We tried to get the "Good Signer" (SDID) lookup with the DKIM STD
>> work. It didn't happen in the
>> market place (it has issues that included the "Batteries Required"
>> syndrome) and even if it did happen, the "Good Signer" methodology did
>> not cover rudimentary DKIM signing failures checks (including missing).
>>
>> In all cases, you need a 3rd party Authorization list somewhere,
>> whether everyone needs one or not, some will, some won't.  That again
>> is also a implementation and business decision.  You can,  in theory,
>> have a more relaxed Signer Engine that double signs all mail or maybe
>> under some rule that allows only outgoing LIST domains to be double
>> signed.   In all cases, this in-band method is still a registration
>> concept, global or selective.
>>
>> The problem has been that some believe everyone will have this a huge
>> need to "register" many domains, and IMV, this erroneous idea has
>> crippled the completion of all DSAP protocols  (SSP, ADSP, DMARC).
>> No, only a few have such "registration" issues, whether thats a
>> million or so, it still a small piece of the total domain space. We
>> won't know how many for sure, but I have a pretty good feel the
>> majority of domains will not need such large "list" needs.
>>
>> How many will you have to collect?   I have 10.
>>
>> e4qssg6j6f6vggflfwk56n6ppxlbglmu._atps TXT	( "v=atps01;
>> d=megabytecoffee.com;" )
>> jchjykxmwknbyfge2bg4td6add264olh._atps TXT	( "v=atps01;
>> d=winserver.com;" )
>> kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT	( "v=atps01; d=gmail.com;" )
>> LYKM653KJ7YXEIA665VA7LSZZTHCX7JJ._atps TXT	( "v=atps01;
>> d=beta.winserver.com;" )
>> n3lsehml2wgbfxov7hsak2qzsubsefhb._atps TXT	( "v=atps01; d=mipassoc.org;" )
>> pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT	( "v=atps01; d=ietf.org;" )
>> q42vdaxs6p26zflt3hcvqey3zp5aivxj._atps TXT	( "v=atps01; d=isdg.net;" )
>> ni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT	( "v=atps01;
>> d=mapurdy.com.au;" )
>> tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT	( "v=atps01;
>> d=santronics.com;" )
>>
>> Are we saying that MOST systems will not be able to handle their
>> Network of known signers?
>>
>> As stated above, this issue is no different than with SPF where larger
>> networks had to learn their network of senders and even then, many
>> still use weak/relaxed policies (~ALL, ?ALL) lowering the payoff of
>> the redundant calls with no actionable results, indeterminate
>> conditions - a high waste most of the time.
>>
>> The MLM or the site mail receivers just needs to make sure it does a
>> ADID/SDID check.  If the WG wants to spend time on a weaker more
>> complex double signature "in-band" solution because the DNS
>> administrator is no longer needed,  that still doesn't mean that this
>> design will be acceptable to all.   The weaker alternative is more
>> code change and if you can avoid code change, the better.  DMARC
>> SHOULD offer the more ideal and simple DNS lookup because it is a
>> natural part of the DNS lookup model that already exist for DMARC
>> which currently isolates itself to the ADID==SDID conditions and
>> automatically failures all other conditions.
> There's a big difference between needing to know the outbound architecture of 
> your own sending (as is needed by SPF and DMARC) and needing to know which of 
> all the places you send mail are mediators.
>
> You seem to think keeping a list of mediators like mailing lists is feasible 
> and offer a way to do it.  I don't have an opinion on how good the method is 
> because I don't there is no way keeping a list can be done regardless of how 
> you store it.
>
> Also, for large providers like (for example) Google Groups, you wouldn't want 
> to authorize them at the domain level since it's a mix of high quality wanted 
> groups and spam groups.  You'd have to do it at the individual mail box level 
> to make it workable.  This only amplifies my concern about scalability.
Dear Scott and Hector,

DMARC offers feedback to help identify where a listing is
needed.  This list can be placed in DNS using hash labels
and TSIG, for example.  There should only be one hash label
function.  Essentially, all the various schemes require
mediators be identifiable.  If it turns out a mediator is a
source of abuse, it should already be in the incoming block
list. Likely another DNS entry.  Since your users will be
unable to see a response anyway don't let users send to
known abusers.  DMARC can signal use of a mediator and flag
this scheme rather than changing or adding DKIM signatures.
No matter the scheme, they all require some form of vetting.
A role that can be played by a repaired ATPS or TPA-Label.

Since mailing-lists are likely to receive special handling
It might be assumed that those allowed to post have been
limited by subscription.  Since a mediator may share a
domain having other uses, TPA-Label is able to differentiate
them to close a subscription gap. Any scheme to enable a
third-party must be very concerned about restricting
access.  How would you envision access be restricted with
draft-kucherawy-dkim-delegate or
draft-levine-dkim-conditional?  In many cases, the From is
already being munged.

Regards,
Douglas Otis