Subject: [dmarc-ietf] An alternative proposal to the known intermediary problem

From: Dotzero <[email-masked]>
Date: Thu, 25 Jun 2020 20:05:43 -0400

After reading Dave Crocker's proposal, which I consider fundamentally
broken, I've given some thought to the issues.

1) Many MLM's do not want to change their current practices yet suffer
consequences from DMARC implementations at their subscribers domains.

2) There is a mismatch between the granularity (domain) which DMARC
operates at and individual subscriptions to mailing lists.

3) It would be useful for domains with individual users to show
authorization for messages by individuals that are likely to flow through
intermediaries such as MLMs.

Without formulating all the details, what I propose for the groups
consideration is a new field which I will call "Intermediary" as a stalking
horse. This field would be DKIM signed separately from the current DKIM
signing. This would ensure more robust survivability in passing through the
intermediary. There would likely need to be some additional elements signed
to mitigate against replay attacks using the second signature.

Variations on this approach might include:

A) Generic signing of "Intermediary". This seems as risky or perhaps more
risky to me as signing using the "*l*=" tag. Presumably generic signing
should not be used in conjunction with reject.

B) Specifying the specific Intermediary in the Intermediary Field. This
would indicate that the users domain recognizes that the user uses the
intermediary and by policy exempts this use even though it breaks both DKIM
and SPF validation. The receiving domain would need to recognize some
potential risk of malicious modifications or additions to the message.

Benefits of this proposal include:

1) This is an addition to DMARC that does not change the underlying
functionality of DMARC for those domains not interested in participating in
this extended functionality.

2) It resolves the mismatch in granularity between the domain level and the
user level as far as authentication/authorization.

3) It would require no effort on the part of known intermediaries other
than not breaking the second signature.

Issues:

1) It increases administrative complexity for the originating domain in
that it requires the domain to either track user:intermediary relationships
or enable users to self approve such relationships ad hoc.

2) A more detailed specification would need to be fleshed out to determine
whether this approach would survive likely modifications by known
intermediaries.

3) This does not address the issue of modifications by intermediaries not
identified in advance and authorized.

Feel free to start pulling this apart. This is a proposal for an approach,
not a complete proposed solution.

Michael Hammer

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 25 Jun 2020 22:15:55 -0400

> not a complete proposed solution.

I think a good place to start is ATPS (RFC 6541).  At least at this level of 
detail it sounds similar to me.  I think it would be useful to know what you 
would do differently or alternately why you think it might catch on now when it 
didn't when it was developed.

Scott K

---

From: Dotzero <[email-masked]>
Date: Thu, 25 Jun 2020 22:36:56 -0400

ATPS requires signatures by multiple parties. What I'm proposing only
requires a 2nd signature from the originating domain. This significantly
simplifies the requirements for the specification as well as ongoing
operational requirements. MLMS or other known intermediaries would have to
do nothing or very little to make sure they don't break the 2nd signature.

As to why there is likely to be adoption now vs ATPS, ATPS was published in
2012 when there was very little adoption of DMARC, specifically by domains
with end users likely to  send mail through intermediaries. The MLM problem
became significantly greater when domains such as AOL and Yahoo! deployed
DMARC with p=reject wreaking havoc among parts of their user base as well
as with MLMs.

I would suggest that the approach I suggest is simpler to implement and
requires less effort than ATPS or Dave's proposed changes to DMARC.

Michael Hammer

On Thu, Jun 25, 2020 at 10:16 PM Scott Kitterman <[email-masked]>
wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "John Levine" <[email-masked]>
Date: 25 Jun 2020 23:20:27 -0400

>potential risk of malicious modifications or additions to the message.

Sounds like what I proposed several years ago:

https://tools.ietf.org/html/draft-levine-dkim-conditional-03

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 26 Jun 2020 11:16:05 +0200

> https://tools.ietf.org/html/draft-levine-dkim-conditional-03

+1, proper verification requires a DKIM version bump.

However, the first point in the issues is new:

On Fri 26/Jun/2020 02:05:43 +0200 Dotzero wrote:
>> Issues:
>> 
>> 1) It increases administrative complexity for the originating domain
>> in that it requires the domain to either track user:intermediary
>> relationships or enable users to self approve such relationships ad hoc.

The problem of how to build such knowledge on user:intermediary
relationships at each mailbox provider might be worth being discussed.

Note that the same knowledge, at the receiving stage would allow
receivers to just whitelist MLMs.  Even if this simpler arrangement
wouldn't survive further forwarding, it is not antithetic to
conditional signatures.

Best
Ale
--

---

From: Hector Santos <[email-masked]>
Date: Fri, 26 Jun 2020 09:27:53 -0400

> https://tools.ietf.org/html/draft-levine-dkim-conditional-03

Ideally, we should offer support for two methods:

1) The non-DNS conditional method,
2) The simpler ATPS DNS method.

The 1st one is more radical code change for additional "double" DKIM 
signing logic.  You will have a segment of the population where this 
is either not be possibility and/or delayed until it can be done.  It 
also comes with security warning from the author.

The 2nd one is simple and plug and play as a DNS lookup challenge 
method. It does not require DKIM changes. It will require slight 
modifications to the DMARC verifier to look for the optional DMARC 
extension "atps=y" tag for 3rd party signing conditions and 
authorization check.

I can support #1 because there will be IETF folks who will say #2 does 
not scale and the DNS lookup overhead can be high with NXDOMAIN 
results. The latter would certainly be true during the early migration 
period in the same way it was true with SPF, ADSP and now ADSP The 
same was will be true with ATPS with NXDOMAIN results.  Over time, we 
will see the payoff as more domains will support the officially IETF 
sanction protocols described in a protocol complete DMARC-PS.

As to ATPS not being scalable?  That is just a question more related 
to DNS storage and management. But even so, having both will address 
all scales and wider implementations where you will have a migration 
period and the easier one will probably be implemented first to get a 
proof of concept and then perhaps adding conditional support for 
higher scale needs.

But I won't repeat what has happen in the past.  I won't support #1 
unless the author is serious about DKIM Policy and show he is ready to 
champion the protocol rather than use this as a way to poison the 
DKIM/DMARC policy effort with a chaotic and self-admission unsecured 
DKIM add-on with no real intention to complete and support.  The 
security section #1 will need to be review to address its described 
replay potential.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: Hector Santos <[email-masked]>
Date: Fri, 26 Jun 2020 09:48:18 -0400

On 6/26/2020 9:27 AM, Hector Santos wrote:

> The latter would certainly be true during the early migration
> same was will be true with ATPS with NXDOMAIN results.

Meant to say:

The latter would certainly be true during the early migration
period in the same way it was true with SPF, ADSP and DMARC with
NXDOMAIN result.

---

From: "John Levine" <[email-masked]>
Date: 26 Jun 2020 21:44:55 -0400

>https://tools.ietf.org/html/draft-levine-dkim-conditional-03

Mike clarified that his suggestion is simpler in that the recipient
can recognize that intermediary however it wants, not necessarily with
a DKIM signature.

This makes me wonder how many mailing lists still don't add DKIM
signatures. Unlike the header rewriting hacks, they don't affect the
way recipients see or handle the mail in their inboxes.

---

From: "Stan Kalisch" <[email-masked]>
Date: Tue, 30 Jun 2020 10:50:55 -0400

> way recipients see or handle the mail in their inboxes.

The HTTPbis list and Full Disclosure immediately come to mind. IIRC, Bugtraq didn't use DKIM, either.

Stan

---

From: Dotzero <[email-masked]>
Date: Tue, 30 Jun 2020 11:08:34 -0400

On Fri, Jun 26, 2020 at 9:45 PM John Levine <[email-masked]> wrote:

> >In article <
> [email-masked]> you
> write:

DKIM signing would certainly make it easier for receivers but I'm hesitant
to try and mandate it  for intermediaries. The 2nd signature from the
originator is a good indicator and depending on which additional fields are
signed should provide reasonable protection against replay attacks.

Michael Hammer

---

From: "John R Levine" <[email-masked]>
Date: 30 Jun 2020 12:17:29 -0400

> to try and mandate it for intermediaries.

Well, gee, it's easier than ARC signing which is what we're asking now.

I am not opposed to asking list operators to make changes, so long as they 
are not changes that force their users to change the long standing way 
they use the lists.  These days all of the MTAs and list managers I know 
can do DKIM signing, so it's not a lot to ask.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John Levine" <[email-masked]>
Date: 30 Jun 2020 12:43:40 -0400

>Bugtraq didn't use DKIM, either.

Bugtraq was started in 1993 and is now dead so I'm not sure how useful
an example it is.  Don't know which httpbis list but the IETF signs all its
mail and if W3C doesn't, they use Exim which is easily adjusted to do so.

The question isn't whether everyone signs, clearly some don't. The
question is how much of an imposition it would be to ask them to do
so. Unless they're using incredibly ancient mail and list software,
not much.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 30 Jun 2020 19:49:51 +0200

On Sat 27/Jun/2020 03:44:55 +0200 John Levine wrote:
> signatures.

Lists at vger.kernel.org and savannah.nongnu.org are not signed.

There are also some which don't seem to have found a way to deliver valid DKIM 
signatures, such as those at lists.sourceforge.net.

Best
Ale
--

---

From: Jim Fenton <[email-masked]>
Date: Tue, 30 Jun 2020 11:00:38 -0700

On 6/30/20 10:49 AM, Alessandro Vesely wrote:
> There are also some which don't seem to have found a way to deliver
> valid DKIM signatures, such as those at lists.sourceforge.net.

Yes; they seem to be signing with both sf.net and sourceforge.net, but
neither signature verifies successfully. Wonder why.

-Jim

---

From: Hector Santos <[email-masked]>
Date: Tue, 30 Jun 2020 14:11:39 -0400

> valid DKIM signatures, such as those at lists.sourceforge.net.

Not all List Systems (MLM, MLS) have a transport system, so it is left 
for the outbound mail processor (mail router) to handle the signing 
for all outbound mail. That is how our MLS behaves. The MLS only needs 
to control the subscription and submissions process by checking the 
DMARC record for restrictive domains.  Really no code change in MLS at 
all related to DKIM.

Abandoned Legacy MLS many be a problem, but any operator who wishes to 
be part of the DKIM/DMARC era, needs to understand it needs some 
controls with subscription and submission checking.  It doesn't need 
to worry about getting support for the abandoned MLS. He just needs to 
control the entry points like subscription and submission.