Subject: Re: [ietf-dkim] That weird i= is most probably EDSP

From: Michael Deutschmann <[email-masked]>
Date: Fri, 2 Aug 2013 17:09:29 -0700 (PDT)

On 22 Jul 2013, John R. Levine wrote:
> >> "EDSP" would be tier 1 both senderside and receiverside.  That's its
> >> selling point. ...
>
> >> TPA ADSP enhancements are tier 1 receiverside and just-barely-above tier
> >> 3 senderside. ...
>
> Did I miss some I-Ds describing these?

TPA ADSP is Otis' baby, not mine.   He has written drafts on it, although
they are expired now.

EDSP is just a concept at the moment.  That's why I sayed "'EDSP' would
be" instead of "EDSP is".

Your question about drafts has two possible implications.  The first is
"I'm not going to pay any attention to Michael until he takes up RFC
lawyering." In which case I can't help you.

Another is that you just want a more concrete proposal to attack.  So:

My fantasy of EDSP is to have it as a new modifier to SPF records.  This
would avoid an extra DNS lookup when deploying it at a receiver that
already checks vanilla SPF.   Burying it in ADSP or DMARC wouldn't work
as well, because then two lookups would be needed in the case that MAIL
FROM: and From: differ.

Only the direct SPF record for the domain would need to be checked - EDSP
would ignore SPF redirections and includes.

(Because of the connection to SPF, I've brought up ideas similar to this
on spf-discuss years ago.  Unfortunately they seem to be in a Not Invented
Here mood regarding DKIM.)

It would be a simple boolean -- either a sender domain has it on or off.

If it's on, then a receiver site would be expected to enumerate through
the DKIM signatures looking for a one that is both valid and where d=
matches the MAIL FROM: domain.  If none is found, then the recipient is
strongly encouraged to 5xx the transaction attempt.  (Obviously bouncing
isn't a good idea.)

Some people here seem to have a problem with the fact that the MAIL FROM:
is not recapitulated in any header that DKIM can protect against
alteration.  I don't get why this would be a serious problem.  It does
mean you can replay a message with the MAIL FROM: altered, but you are
still restricted to domains that have signed the message and cannot alter
the body.  I don't see the use to the bad guys.

---- Michael Deutschmann <[email-masked]>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 3 Aug 2013 05:18:21 +0200

> lawyering." In which case I can't help you.

My problem is that absent a draft, you're lobbing a vague proposal over the
wall and hoping the community will do all of the work for you.  If your
idea is a workable solution, I think it's reasonable for people to be
convinced first that it's worth taking up the work.  Popular forms of
evidence are detailed specifications that can be analyzed and/or prototype
implementations.

As for your proposal, assuming I've understood it:

The idea of requiring a first-party signature relative to the MAIL FROM,
and using SPF to signal the requirement, runs into a couple of problems.
The most obvious of these is that it presumes the author is covered by SPF,
which is not universally true; the sending infrastructure may have chosen
not to publish SPF due to false positives.  That means this proposal is
only useful to a subset of the community.  That's a significant barrier.

The community reached consensus some time ago that the absence of a valid
first-party signature is not a reason in and of itself to distrust the
message, because there are legitimate reasons DKIM can fail, and legitimate
cases where a third party signs the message instead of the author domain.
The DKIM RFC does state this fairly clearly.  It's only the case where DKIM
passes that you have actually learned something useful about the message.

>From a protocol design perspective, using one protocol to signal an option
in another almost orthogonal protocol is pretty weird.  Coming up with
standards-worthy signaling between the two, since SPF is almost always
upstream of DKIM in terms of MTA processing, would be an interesting
exercise.  Otherwise you're presuming a single component is doing both
tests, which is not commonly how it's done.

All that said, I invite you to spend some time building an implementation
and gathering statistics on its efficacy.  Such data speak pretty loudly.
There are plenty of APIs that would enable you to build something like this
and try it in short order.  If you decide to use libopendkim as part of the
experiment, I pledge to support it; if it looks like your solution is
useful, and the signalling question can be resolved, I'll add it to
OpenDKIM.

Another more general problem is that you appear to reject all of my mail
because Gmail generates HTML mail, so hopefully you check the archives of
this list once in a while.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 4 Aug 2013 19:56:04 -0000

>wall and hoping the community will do all of the work for you.

That was my sense, too.

Writing a draft and submitting it is not a huge effort (at least, not
if you know what you're going to say), and it has the advantage that
it gives a stable reference for people to see what you're proposing.

R's,
John