Nathaniel Borenstein wrote:
I find it amazing how many different ways there are to criticize DKIM
for not doing something it was never intended to do. DKIM is a small
building block that enables new functionality, but such functionality
is beyond the scope of DKIM.
Note: We have an advanced implementation of DKIM as a product line so
my concerns are not outsider views. My input is 100% based on
implementation and field experiences.
Policy was very fundamental to the understanding of DKIM, it was part
of the original DomainKeys and DKIM expanded this powerful concept
with a wider range of Author Domain policies.
I never disputed the out of scope 3rd party trust policy model but it
addressed a different problem - trust, if any, of a valid signature
after the violations are filtered by author domain policies, if any.
Two different layers and this was outlined in my 2006 DKIM Signer
Authorization Protocol (DSAP) I-D.
The problem was a conflict in different market ideas - an unrestricted
resigner DKIM mail market which 1st party security controls would
conflict with. They simply did not want the 1st party to override
any 3rd party signers. This conflict was highlighted in the SSP
requirements with the last minute addition in RFC5016:
"Requirements for a DKIM Signing Practices Protocol"
when item #10 was added in section 5.3 to appease the opponents of 1st
party SSP polices:
10. SSP MUST NOT provide a mechanism that impugns the existence of
non-first party signatures in a message. A corollary of this
requirement is that the protocol MUST NOT link practices of first
party signers with the practices of third party signers.
INFORMATIVE NOTE: the main thrust of this requirement is that
practices should only be published for that which the publisher
has control, and should not meddle in what is ultimately the
local policy of the receiver.
Refs: Deployment Consideration, Section 4.3.
This was unfortunate. On the one hand it suggest we should not meddle
in how local receivers will behave yet it imposes a MUST NOT mandate
in allowing the 1st party policy to override a 3rd party signature
trust policy.
DKIM does one thing, and one thing only: It uses a cryptographic signature
to associate a domain with a message.
It does more than that. DKIM has a fundamental requirement to hash
bound the 5322.From field to the signature. Its the only header that
MUST be signed. All others are optional. This 5322.FROM bind provide
the only anchor possible that can be repudiated.
So there are two principal domains associated with a signature:
Signer d= value in signature
5322.From DKIM requirement
By doing so, it creates strong evidence that the message passed
through that domain at some point and has not been significantly
modified since.
I don't see this. The resigner can be totally opaque with no
association with the original domain. The signer::author association
begins with the original signature creation by the author domain
selecting a signer and/or prearranged with an outsource signing service.
Now, what people are looking for as well, is when there is
resigner::author association when the author is participating in a
resigner network. Currently we call this a 3rd party Authorization.
With such an anchor, we can begin to build stronger and more robust
systems for analyzing the desirability of messages, as we are now trying
to do in the REPUTE work, because it allows us to push our forensic
analysis upstream a bit.
Heuristic wrappers are interesting but its a different problem. It
doesn't adequately address what a deterministic solution can do for you.
If, for example, the IETF mailing list software only allows posting
by list members, but itself trusts the sender's header fields, then
an IETF DKIM signature tells me only that the IETF servers think a
message passed that test.
There you go, you made an POLICY STATEMENT - translate it into a
protocol for everyone to follow and check.
That's obviously not perfect, but it's slightly stronger than what came
before -- it is still possible to forge a message before sending it to the
list, but much harder to forge a message to look as if it came from
the list exploder.
This is all besides the point. Its all about detection what YOU think
is a violation of a protocol logic. Whatever you produce in REPUTE,
you are producing a idea for people to follow consistency based on
some baseline rules established.
We've had a long history of grand plans for user authentication on
the Internet. Those plans have largely failed.
There are plenty of authentication protocols that works very well, and
fundamental to our current network.
The issue here is a DKIM signer market run wild uncontrolled and if we
don't get our act together soon to put a security wrapper around it,
it risk becoming yet another wasted header with little to no value and
perhaps limited to exclusive communications in private communications
networks.
I think an incremental approach like DKIM has a better chance,
but it is obviously vulnerable to being dismissed by those who
see a small improvement as not worth bothering with. The best is
the enemy of the good. -- Nathaniel
I have invested dearly in dollars, time and energy and we have
produced an advanced DKIM implementation into our product line with a
high degree of mail component integration - its a commercial product,
not just for our own use.
My concerns are 100% sincere as I believe that it might not be too
late for DKIM to correct what has occurred - the deemphasis of the
single DKIM requirement to hash bind the 5322.FROM author to the
signature means.
This is an association you can not ignore because the entire mail
infrastructure relies on the 5322.From as a fundamental header across
all mail networks, all mail devices, etc, etc. etc. This is a not a
question that can be separated which unfortunately the DKIM
specification Abstract states as a goal of DKIM:
DKIM separates the question of the identity of the signer of the
message from the purported author of the message.
What question is that? Is the question this?
Do author domains have any say on who signs for them
and who/what is considered unauthorized signatures
versus authorized resigning?
Anyway, thanks for your comments.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf