[ietf-dkim] on the scope and necessity of threat analysis
arvel at altn.com
Sat Aug 13 16:21:21 PDT 2005
> what is the most minimal enhancement that would make
> you happy TODAY?
> define requirements that dkim satisfies, without
> actually saying anything about the details of dkim itself.
Why the "most minimal" qualifier in your question? We are capable of
producing something more than the bare minimum.
Here we go:
IETF, please do the following things for us domain owners and email users:
FROM = the domain in the RFC2822.From header of an email message.
(a) Define a specification that I can use to digitally sign my email
messages in a way that recipients with compliant technology can verify.
Why? Because people are receiving messages today which claim to be FROM my
domain and I have no way of proving to them that they really are.
(b) Define a specification that I can use which grants me the ability to
verify signatures when I receive messages signed by others. Why? Because I
can not today trust the validity of the email that I receive. It says it's
FROM 'yahoo' but is it?
(c) Define a specification that I can use which provides a means of
detecting message content change. Why? Because I want my email to arrive
at its destination substantially unaltered and I expect to receive email
from others substantially unaltered.
(d) Define a specification which grants to me the ability to communicate to
others whether messages FROM my domain should contain signatures or not.
Why? Because I would like to be able to provide to others a means by which
they can determine whether unsigned or improperly signed messages are "ok"
with me. After all, it's my domain in the FROM; I want a connection between
myself as a domain owner and any email from any source which claims to be
FROM my domain.
(e) Define a specification which grants to me the ability to discover
whether unsigned or improperly signed messages are "ok" with the domain
owner who's name is being used in the FROM header. Why? "Do unto others as
you would have them do unto you". Basically, I'd like the same courtesy
extended to me that I extend to other domain owners.
> any benefit in just being able to deal with a signature that
> is present, without knowing whether it is 'supposed to be'?
Of course. But there is *enhanced* benefit when you can couple the
existance of a signature with the particular wishes of the domain in the
FROM header. This is what DKIM does. It's what it's parent specifications
did and it's what draft-allman-dkim-ssp describes. That document is every
bit as "DKIM" as the signing document is. I could easily turn the question
around: Is there any benefit in just being able to know whether a domain
requires signatures in messages proporting to be from it? Or course there
> Again, that's a summary of very particular policies.
Well, that's what you asked me for :)
> What about the utility of a signature, without being able
> to check on domain-wide policies.
We're beating a dead horse with this question. Yes, there is value here.
But this is nowhere near the extent of the value that DKIM provides. Are
you wanting to restrict the value of DKIM to only the utility of signatures?
Do you assert there is no value in draft-allman-dkim-ssp?
> remembering that dkim is a transit-time assurance
> mechanism, why do you care whether the validated
> identity is specifically "who sent you" the message?
I did not communicate my thinking very well in the last post. Lets look at
this a different way then. I don't care "who sent" the message. I only
assert that the domain in the RFC2822.From header will be assumed to be the
"sender" by humans. If that field has my domain in it, I have a right to
say something about that by defining a mechanism through which compliant
verifiers can know under what conditions I allow my domain to exist in *any*
RFC2822.From header whether I'm the "sender" or not - whether a list
exploder is the "sender" or not - whether it's forwarded, canned, bottled,
boxed, I don't care. If *my* domain is in the FROM, I've got something to
say about that. This is what draft-allman-dkim-ssp provides and this has
> or examine none. just look at the signature header.
This tells me only who signed the message, which is useful, but not
exhaustively so, and isn't even possible in the case of unsigned mail.
Unless the signing identity happens to match the RFC2822.From domain more
can be done and more is certainly required (at least for now) by the current
> if that header says 'ebay' and validates, do you REALLY
> care whether it matches any of the header fields?
> if that header says "spammer.example.com" and validates,
> do you REALLY care whether it matches any of the header
Ok, these questions assume the point of view of an email consumer rather
than a domain owner. I'm interested in both perspectives.
Here's how I see it: If I have a signature saying 'ebay' - this is good, as
you continually point out. I can run 'ebay' through my local policy filters
and/or reputation assessment etc. So, that's all good (as far as it goes).
BUT if the RFC2822.From field in that message says anything OTHER THAN
'ebay' I'd like to extend the courtesy of a DKIM policy lookup on *that*
domain and I'd very much appreciate the courtesy of the reverse. This is
*also* very useful input into my filters. From the domain owners side of
the equation, I am not 'ebay' - I am 'altn'. So when a message has 'altn'
in the RFC2822.From header I don't care whether it has a *thousand* digital
signatures saying 'ebay' or anyplace else. I would like you to do a DKIM
policy lookup and see what I have to say about that. This is what
draft-allman-dkim-ssp is all about.
> Unfortunately this means that you think that recipient
> users have a role to play in valdiating received mail.
If you wish to define 'role' as a valid reason to pick one identity header
over another for the purposes of draft-allman-dkim-ssp, then yes, why not?
Can you provide me with a reason why Sender or some other header should be
preferred instead of From?
> Really. They can't. They do not understand enough to do
> the task, they are not trained well enough to do it
> regularly/reliably, and it is entirely unreasonable to impose
> on them this burden for something as basic as message
I'm completely lost here. We're not asking end users to do anything. We
are merely recognizing the fact that the RFC2822.From header is assumed to
be the "sender" by naive users. We ask neither for their input into the
verification process, nor are we asking them to educate themselves on what
"sender" really means. To the contrary, by selecting the RFC2822.From
header over other identity headers in draft-allman-dkim-ssp we are meeting
users where they are. We ask nothing of them. So, I completely don't
understand your concern here.
> First of all, I don't recall publishing domain-wide policy
> as being an essential part of either of the proposals.
Well, Mark and Jim are more qualified to speak to that but I know this:
DomainKeys 2. DomainKeys Overview
In the event that an email arrives without a signature or when the signature
verification fails, the receiving system retrieves the policy of the claimed
sending domain to ascertain the preferred disposition of such email.
DomainKeys 3.6 Policy statement of sending domain
While the disposition of inbound email is ultimately a matter for the
receiving system, the introduction of authentication in email creates
a need for the sender domain to indicate their signing policy and
preferred disposition of unsigned email.
DomainKeys 3.7.6 Retrieving sending domain policy
In the event that an email fails to verify, the policy of the sending
domain MUST be consulted.
There are similar provisions in IIM. See the "Support for NULL Key Check" in
the IIM white paper.
> Second of all, retaining any particular feature of either hardly
> seems a compelling goal.
I didn't mean to suggest that it was. I merely pointed out that DKIM sans a
required SSP check would be a very different animal than what we have
currently and would be a fundamental departure from it's parent
specifications. It would produce a product 1/2 as useful as it is currently
(in my view). We'd have merely a signature signing/verifying methodology -
and before you ask it again, yes, such a thing is useful :)
The question isn't is there "any benefit in just being able to deal with a
signature that is present, without knowing whether it is 'supposed to be'?"
The answer to that is so clear, it's hardly worth asking. The real question
is whether the group wishes to restrict DKIM to providing only or primarily
this benefit by crippling (or perhaps removing?) the policy provisions. My
view is that such a move would be a mistake.
More information about the ietf-dkim