[ietf-dkim] on the scope and necessity of threat analysis

[Arvel Hathcock]

> 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 
is.

> 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 
terrific value.

> 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 
draft documents.

> 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
> fields?

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
> delivery.

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.

-- 
Arvel