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
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
