Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support

[Douglas Otis <[e-mail]>]

On 4/30/15 11:08 AM, Hector Santos wrote:
> On 4/29/2015 3:09 PM, Murray S. Kucherawy wrote:
>>
>>     If OpenDKIM is popular among many big systems, it
>> would make sense
>>     to slightly update OpenDKIM so that the "atps=y"
>> option is based
>>     off a DMARC lookup.   The change is small.
>>
>> Sure, if that's consensus.  That would also involve
>> promoting ATPS to
>> the Standards Track, but to do that we'd need to see some
>> hope that
>> widespread deployment is likely.  But we still have that
>> pesky
>> registration problem to deal with.
>
> Registration is a different situation that is tied to the
> market place.  It should not be a barrier to the IETF
> technical protocol we wish to provide as a IETF
> recommended solution.
>
>>     Maybe Murray can explain how its setup and triggered
>> in OpenDKIM.
>>
>> If you enable it, you just have to name which domains you
>> authorize to
>> sign for you.
>
> So if I understand RFC6541 (its unfortunate I wasn't
> around during work):
>
> Given two identities:
>
>   ADID  Author Domain Identity (5322.From.domain)
>   SDID  The signer domain identity to be placed in "d="
>
> 1) The DKIM signer MUST add tag "atps=SDID" to DKIM-Signature
> 2) The DKIM signer CAN add tag "atpsh=hash" to DKIM-Signature
>
> At the DKIM ATPS compliant Verifier:
>
> 3) It takes atps=SDID and atps=hash to do the hash(ADID,
> SDID) lookup.
> 4) A positive results signifies authorization, allowance.
>
> Correct?
Dear Hector,

My initial feedback on this was ignored.  The matter became
worse due to demands made by IESG out of DDoS concerns.

The required use of a special DKIM signature is not
practical for at least two reasons.

1) The label encoding used by a first party CAN NOT be
directly ascertained! (There should only be one encoding
scheme.)
2) It expects mediators to establish relationships with all
first party domains. (Special DKIM signatures should be
replaced by DMARC assertions to allow normal DKIM signatures
AND other verification methods.)

Imagine offering a free service. Because of a few
irresponsible ESP making false assertions about their
message alignment, this then requires all secondary services
to establish a database against tens of thousands of
domains.  This effort is absolutely reasonable for the large
ESPs attempting to assert restrictive policies, it is not
reasonable for tens of thousands of third-party services now
expected essentially replicate this effort. TPA-Label offers
a much cleaner solution that does not require the use of
DKIM or SPF. Use of a special DKIM signature actually
increases DDoS concerns.
> In the original ATPS drafts, in step #3 would of been:
>
> 3) Do a ADSP lookup, if "atps=y" tag found, do hash(ADID,
> SDID) lookup.
>
> Correct?
>
> Well, I think you prematurely removed the ADSP dependency.
> Wish I was there to object.  Making it based off DKIM
> increased the adoption barriers with a DKIM change
> requirement.  This would be one big reason for no traction.
>
> Anyway, I think we can simplify this.  Back when RFC5016
> was being done, an implementation debate regarding when to
> do the policy lookup, under what condition.  Concerns of
> too much DNS wasted calls, etc. The threat analysis
> RFC4686 pretty provided a consensus that the only time we
> really needed to do the lookup was under the mismatch
> condition:
>
>        ADID != SDID
>
> Doing a lookup even under ADID == SDID condition did allow
> for addition policy offerings such as:
>
>   o Domain has no mail operations
>   o Domain does not sign mail
>
> But these events can be folded with other fail conditions
> so it wasn't necessary to do a lookup for a valid 1st
> party signature.  After all, the Trust Lookup of SDID was
> the next step in this total DKIM+POLICY+TRUST process.
>
> So in short, all these extended ideas for a DSAP, TPA,
> ATPS, etc, can be done when the ADID != SDID condition
> exist.  No "atps=y" dependency on any other protocol like
> ADSP, DMARC and DKIM.
>
> The mismatch condition is enough of a signal to run an
> optional 3rd party authorization check.  I understand the
> reason for the "atpsh=" tag, but we can do it with a
> default hashing method.
Absolutely.  In fact, you should be able to use a simple
assertion in the DMARC record and leverage existing DKIM
signatures AND other authentication schemes.  I would be
happy to go over what it would take for the information
contained in these schemes to be compatible, but why?  It
seems going to the trouble of establishing third-party
profiles, this effort should anticipate what might be needed
to help mitigate expected abuse. (Reducing the attack
surface so to speak.)

My latest draft on this matter offers a simple solution
requiring minimal registration << 100.

Regards,
Douglas Oits