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

From: Hector Santos <[email-masked]>
Date: Wed, 29 Apr 2015 13:16:43 -0400

I downloaded OpenDKIM source code to see whats it offers. I believe I saw:

o ADSP was no longer supported, pulled. Grep showed one instance of an 
inline comment referring to ADSP.

o ATPS was offered, but I failed to see how it was hooked into ADSP 
because it ADSP was pulled.

o DMARC was offered.

ATPS was suppose to be based off the ADSP record with the optional tag 
"atps=y" I believe that is how it worked.  If the "atps=y" was present 
in the ADSP record, then ATPS was supported and an ATPS_Hash(ADID, 
SDID) lookup was done.

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.

Maybe Murray can explain how its setup and triggered in OpenDKIM.

Once it is in place, systems can finally experiment with ATPS records 
authorized 3rd party signers. Larger Systems or any system can explore 
registration systems, proprietary, free or otherwise.

There would be no more excuses with an 3rd party policy solution made 
available to help the legitimate MLM resigners.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 29 Apr 2015 12:09:37 -0700

> inline comment referring to ADSP.

Correct.

> because it ADSP was pulled.

It has nothing to do with ADSP.

o DMARC was offered.

OpenDKIM doesn't know anything about DMARC other than the fact that
"dmarc=" is an Authentication-Results field is not a syntax error.
OpenDKIM runs in the milter stream before OpenDMARC does, and OpenDMARC
consumes the results OpenDKIM provides.

> "atps=y" I believe that is how it worked.  If the "atps=y" was present in
> the ADSP record, then ATPS was supported and an ATPS_Hash(ADID, SDID)
> lookup was done.
>

Nope.  See RFC6541.

> 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.

> 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.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Wed, 29 Apr 2015 16:18:11 -0400

On 4/29/2015 3:09 PM, Murray S. Kucherawy wrote:
> On Wed, Apr 29, 2015 at 10:16 AM, Hector Santos <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     o ADSP was no longer supported, pulled. Grep showed one instance
>     of an inline comment referring to ADSP.
>
>
> Correct.
>
>     o ATPS was offered, but I failed to see how it was hooked into
>     ADSP because it ADSP was pulled.
>
>
> OpenDKIM runs in the milter stream before OpenDMARC does, and
> OpenDMARC consumes the results OpenDKIM provides.
>
>     ATPS was suppose to be based off the ADSP record with the optional
>     tag "atps=y" I believe that is how it worked.  If the "atps=y" was
>     present in the ADSP record, then ATPS was supported and an
>     ATPS_Hash(ADID, SDID) lookup was done.
>
>
> Nope.  See RFC6541.

huh?  Ok, I see what happen, I was working off early drafts when ATPS 
was an extension to ADSP.  I can see it changed in rev 05 and in the 
final RFC6541 production it was made an in-band extension to DKIM.

I don't have time to read it all now at the moment, but it is only 
meaningful when a DKIM signature is present?  What happens when it is 
missing?

I wanted to keep a extension to the policy lookup that was already 
being done. No change to DKIM was necessary.  Could this be a reason 
why they was no traction?  I can see why now.  It required a change to 
the DKIM engine.

As an extension to ADSP as the original proof of concept was (often 
the best idea), what I did was two new tags:

    asl=[list of resigners]
    atps=y                    use ATPS

This allows for a small and large scale.   I only need 10 domains and 
I can fit domain in my "asl=" tag.  Large scale can use atps=y instead.

So does DKIM require the atps|atpsh tag before an ATPS lookup can be done?

-- 
HLS

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 30 Apr 2015 17:13:30 +0900

Murray S. Kucherawy writes:

 > we'd need to see some hope that widespread deployment is likely.
 > But we still have that pesky registration problem to deal with.

IMO there is no registration problem for mailing lists for this WG.

True, if big p=reject domains won't buy in, it's probably not worth
our effort to even think about it.  But if they *are* willing to buy
in, registering a *lot* of mailing lists, probably the great majority,
requires only parsing the List-Post header out of incoming posts, then
adding this to a global list or to the subscriber's profile.

Indeed, registration itself is a cost, a small amount of storage space
per user, a user database schema change I suppose, plus the changes to
the MTA (or MUA or MDA/submission agent) to hook into the user data
base to update the users' lists of lists and access them for third-
party authorization.  But these aren't huge changes, the costs can be
estimated reasonably accurately I suppose, and I doubt they are
prohibitive.

This automated registration scheme may provide a vector for abuse (the
spammer can get any address registered they like), but in the per-user
case it's limited to one user, and only posts originating in the
Author Domain can get the authorizing signature.  Paranoid Author
Domains might even overlay an "explicit opt-in" scheme to reduce the
attack surface.  Getting lists that don't provide List-Post would
require some manual scheme, but I don't see that as a huge barrier
either.

The point is not that *we* should "standardize" such a scheme, just
that it's feasible to automatically register enough of the lists
actually in use by a domain's mailbox users to be worthwhile.  For
mailing lists, registration is not *our* problem.

---

From: Franck Martin <[email-masked]>
Date: Thu, 30 Apr 2015 09:27:59 -0700

> On Apr 30, 2015, at 1:13 AM, Stephen J. Turnbull <[email-masked]> wrote:
> 
I log any rejected email that has a List-Post or List-id (not all MLMs use List-Id). I see a lot of marketing emails and spam with these headers. So there is a need to make sure this is really a MLM. It is not overly complicated, considering I’m mostly the only one to subscribe to MLM with my corporate email address, but I wanted to mention the presence of such headers is not foolproof.

---

From: Hector Santos <[email-masked]>
Date: Thu, 30 Apr 2015 14:08:22 -0400

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.

> 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?

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.

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Thu, 30 Apr 2015 12:03:02 -0700

On 4/30/15 11:08 AM, Hector Santos wrote:
> 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.
>
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.
> 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:
>
> 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

---

From: Kurt Andersen <[email-masked]>
Date: Thu, 30 Apr 2015 10:03:08 -0700

On Thu, Apr 30, 2015 at 9:27 AM, Franck Martin <[email-masked]>
wrote:

>
> I log any rejected email that has a List-Post or List-id (not all MLMs use
> List-Id). I see a lot of marketing emails and spam with these headers. So
> there is a need to make sure this is really a MLM. It is not overly
> complicated, considering I’m mostly the only one to subscribe to MLM with
> my corporate email address, but I wanted to mention the presence of such
> headers is not foolproof.
>

With List-Id becoming a more generic feedback channel, I suspect that its
value for indicating the participation of a MLM will further degrade.

--Kurt Andersen

---

From: Douglas Otis <[email-masked]>
Date: Thu, 30 Apr 2015 16:30:11 -0700

On 4/30/15 10:03 AM, Kurt Andersen wrote:
>> It is not overly
Dear Kurt,

Rather than seeing List-ID as representing feedback, it can
be used to restrict the scope of an authorization scheme as
a way to acknowledge a known relationship closely monitored
by the domain granting authorization.  Limiting the attack
surface so to speak.  This would allow less disruptive
methods in seeking cooperation in the removal of an errant
participant as described by TPA-Label.  TPA-Label does not
require modifications made to current verification schemes. 
It simply leverages available identifiers using a highly
scalable authorization method with little DDoS risk.

Domains wishing to improve protections beyond what a
"public" assertion would allow can adopt TPA-Label to offer
actionable and lower disruptive policy handling request
adjustments. Such "pointy stick" feedback better ensures
cooperative message handling.  When authorization is based
on comprehensive message signatures, this feedback can not
be leveraged by malefactors.

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Thu, 30 Apr 2015 23:50:20 -0400

On 4/30/2015 1:03 PM, Kurt Andersen wrote:
> On Thu, Apr 30, 2015 at 9:27 AM, Franck Martin <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     I log any rejected email that has a List-Post or List-id (not all
>     MLMs use List-Id). I see a lot of marketing emails and spam with
>     these headers. So there is a need to make sure this is really a
>     MLM. It is not overly complicated, considering I’m mostly the only
>     one to subscribe to MLM with my corporate email address, but I
>     wanted to mention the presence of such headers is not foolproof.
>
>
> With List-Id becoming a more generic feedback channel, I suspect that
> its value for indicating the participation of a MLM will further degrade.
>

Our operators have signing rules that can use List-ID to determine 
when to sign and with various signing options. For example;

[list-id:*]
Enable=1
AddBodyLength=0
StripHeaders=DKIM-Signature

Are you suggesting they might want to strip the List-ID for some signings?

StripHeaders=DKIM-Signature:List-ID

-- 
HLS