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

[Hector Santos <[e-mail]>]

On 4/9/2015 5:47 PM, Murray S. Kucherawy wrote:
>>
>> Every Google Apps domain has mailing lists (Google Groups) support, should
>> I put all of them automatically on such a list?  That's way more than 50k
>> records at that point, and even if they're paying me (Google) money, I
>> don't know if I would trust them to send from gmail.com or google.com.
>> Currently, for sending mail as google.com, we require vendor level
>> security audits... am I supposed to just say "ok" to every random mailing
>> list that googlers are on?
>>
>
> This is precisely why I am "showing my disinterest in completing the DKIM
> ATPS work", and also why I don't think things like DSAP or TPA will work
> either.  They all amount to creating a registration burden on the author
> domain, and those sorts of approaches do not scale.

It is still not convincing.  You are already doing a DMARC lookup. You 
are adding a new parameter to the DNS lookup and only when the ADID != 
SDID condition is met.

The registration is a long term process, just like SPF and now DMARC 
was.

> Solutions to this problem have to be self-contained in order to stand a
> chance of being viable.  The drafts before us now attempt to augment DKIM
> in a way that doesn't create any extra queries to the DNS or any other
> registry to validate.  So far, this seems way more palatable.

I'm sorry, but its not.  It would be more DKIM changes at the all 
points. It is not necessary to be done. Certainly more processing 
overhead and there are additional DNS calls.  For each new 3rd party 
signature, you got a DNS hit.  You can't avoid the DNS hit.   Adding 
ATPS/TPA to DMARC adds only 1 more DNS call and thats only when the 
ADID != SDID.

And how do you expect the new signer to learn when to create two 
signatures?  Where is that registration coming from?   Google still 
needs to learn 50K domains and also figure out how to automate it for 
Google Apps mailing list support.   Its no different Murray.

At this point, you need both ideas:

    If there is a @FS= record, check it, otherwise if ADID != SDID 
check ATPS.

DKIM signers and verifiers should not be put into a design change and 
cost burden when its not necessary.

-- 
HLS