Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion

[Hector Santos <[e-mail]>]

On 5/31/2019 8:08 AM, Doug Foster wrote:>


>Tactically, what I meant was "IETF should be able to ensure that IETF
> messages are only released with verifiable IETF signatures".
>
> This would mean that either the first signature is not applied, the message
> is not altered after the first signature is applied, or the first signature
> is removed after the message is altered.   The current configuration leaves
> open the suspicion that IETF has rogue software operating in its
> environment.  I am aware that the DKIM specification says to treat an
> unverifiable signature as a non-signature.   This is not a sufficient reason
> to release your own organization's signatures onto the internet when you can
> or should know that they will fail validation.


If I may.

In principle, I agree the IETF should be the "poster-boy" of the 
technologies and methods it helps engineer.

Unfortunately, it is an ideal concept but not always practical nor 
possible to implement the proposals.  In fact, with DKIM, there is a 
standard base but with the DKIM POLICY model, there is no standard. 
DMARC is not a proposed standard. It is an Informational Status 
document, meaning, it really has no "power."   You can try to throw 
"the book" at someone's face for non-compliance  and will throw it 
right back saying "its not a standard. I don't have to follow it."  So 
that is one thing that needs to be corrected.

There is only one simple reason why DMARC was introduced as an 
Informational Status guide.  Under this status, it would not have to 
go through IETF engineering and review process.  There was a period a 
few years back where this Info Status method was used to "fast track" 
documents.   If DMARC was introduced as a proposed standard, it would 
of, undoubtedly, had a rough time getting endorsed, especially since 
the IETF was just told to abandoned ADSP for problems DMARC never 
resolved.

DMARC came after many years with earlier versions of DKIM Policy 
proposed methods with many heated discussions between Policy Model 
advocates and Non-Policy Trust Model advocates.

History of DKIM Policy (as I lived it):

Before DKIM, there was Domainkeys (DKEYS) and DKEYS introduced the 
powerful concept of Signature Policy with the "o=" tag:

     o = Outbound Signing policy ("-" means that this domain signs all
         email, "~" is the default and means that this domain may sign
         some email with DomainKeys).

So you had two Policy options:

    o=-  Exclusive Signing. Mail is always signed.
    o=~  Neutral, Maybe you signed, maybe you didn't.

This was a powerful new concept and many people, the news rags, got 
really excited about it because for the first time, we had a 
deterministic method to reject mail based on a published rules by the 
domain on what to expect.   SPF offered this too via the hard -ALL 
fail policy which was catching on with more domains using -ALL.   I 
expected the same would happen with DKIM Policy.  In fact, DKEYS was 
viewed as a replacement for SPF because SPF had the "Node IP 
Transition" problem in multi-hops.  With Domain Signature Policies, 
ideally, we could avoid the SPF IP problem.  If the domain said "My 
Mail MUST be signed by Me" and the mail was in fact, not signed or was 
invalid, then the receiver had a new gained power and permission by 
the domain to reject/filter mail with no questions asked. In other 
words, it was no longer censorship.  We were given the legal power to 
reject based on what the DOMAIN publicly published.  SPF and DKIM 
Policy were the only protocols to offer this to mail developers.

But what about 3rd party signatures?  What if other domains signed on 
your behalf?  What about List serves?  Can we publish some rules about 
3rd party signers?

Following DKEYS lead, DKIM was introduced with extended "o=" policies 
called SSP (Sender Signature Policies or Practices).  After much WG 
discussions,  they were summarized:

    DKIM-SSP/WG Proposed Policies

    o=-  STRONG  (1s party signature required, 3rd party allowed?)
    o=~  NEUTRAL (signature optional, 3rd party allowed)
    o=!  EXCLUSIVE (signature required, no 3rd party)
    o=?  WEAK (signature optional, no 3rd party)
    o=.  NEVER  (no mail expected)
    o=^  USER

One of the questions with DKEYS "o=-" was if it supported a 3rd party 
signature.  Did the domain expect it to be routed via middle ware with 
additional signatures?

The tag "o=!: was introduced to clear up that question, making it an 
exclusive, restrictive signing practice.

But we also worked on how we can authorize a 3rd party and that was 
where little agreement could be reached.  We could not agree on what 
the ser Policy (o=^) would be. How will that lower granularity of 
authorization work?  How would we deterministically trust a list 
server resigning a message that will break the 1st party signature?

This complexity is the reason early DKIM drafts was split into 
DKIM-BASE and DKIM-POLICY using SSP, but SSP was replaced with ADSP 
which reduced the policies to just:

    DKIM=DISCARDABLE
    DKIM=ALL

effectively attempting to remove the 3rd party signature issues.

Unfortunately, while it tried to get systems to ignore the 3rd party 
question, the reality was when a list submission occurred, the 
receivers would reject the invalid signatures and now the process of 
unsubscribing list members when the distribution failed at the 
receivers.  We didn't see occured with ADSP but we knew it can happen. 
Not many receivers, if any, were yet supporting or honoring ADSP and 
certainly none of the List Servers supported policy.  So it did what 
it always did.

This was the main reason ADSP, a Proposed Standard, was abandoned. But 
ironically, DMARC replaced ADSP as an informational status document 
for avoid the IETF engineering process. It did not address the ADSP 
problem.  I think people wanted the reporting part of it to learn the 
reasons and locations of failure/rejects.   But DMARC, as we all well 
know, has the same problem and once receivers began to honor it and 
domains began to use DMARC p=reject, we began to see the problems we 
always expected could happen and it did - big time when Yahoo.com 
published the DMARC p=reject policy.

Nonetheless, DMARC took off. The reason why it took off was because 
since day one, since DomainKeys invented it,  we could not remove that 
powerful concept of Exclusive DKIM Policy Signature models where we 
have a permissible mechanism to reject/discard mail.   That is a 
powerful concept and it only has a problem with the 3rd party 
signatures that we have refused to tackle in earnest.

Stepping back to the 3rd party authorization design need. There is/was 
a 3rd party signature authorization proposal called ATPS (Authorized 
Third Party Signature).   This is a simple mechanism that allowed you 
to published which 3rd party domains are allowed to sign on your behalf.

My package supports ADSP+ATPS and now DMARC+ATPS.  ATPS works.  You 
can create records using these wizards:

http://www.winserver.com/public/wcadsp
http://www.winserver.com/public/wcdmarc

So there you go.  Short history as I lived it.

I've been involved with this whole thing since day one. I am firm 
believer in the DKIM POLICY model. The concept is too strong and "it's 
scary" as one prominent person here once put it, and I think one day, 
we will finally figure it out.

I just hope we don't waste too much time with ARC.


Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com


-- 
HLS