Re: Extending DKIM through an identity tag

Hi Dave,
At 09:16 17-10-2009, Dave CROCKER wrote:
>What exactly does it mean to be "tied to"? What is the exact
>assertion that one can make when this tied to relationship is present?

A message can have multiple DKIM signatures. OpenDKIM already
supports that for signing. Messages to a mailing list may be DKIM
signed as they go through it. Currently, it is not possible to
determine whether the message was signed by the mailing list. We
could use heuristics or communicate the information out of band. By
"tied to", I mean communicating the information through a DKIM
tag. I'll use this mailing list as an example. You can use the
assertion the (mailing list) signer is making, i.e. it's saying that
it is a mailing list and that it can be identified through the
List-Id:. Note that whatever the signer or sender says, it's up to
the verifier to decide what policy to adopt.

>What are the specific semantics?

I'm using "tied to" for now. I don't have a proper definition yet.

>What does it mean to be NOT tied to?

I would say that "not tied to" is what we have in the existing specifications.

>What benefit comes from being able to "prove" that the identities
>have this tied to relationship? "help receivers validate...
>signatures" probably implies the answer to my question, but I woudl
>appreciate your elaborating on this more.

We have a verified signature and some identity (AUID or SDID). We
pass the information through the Authentication-Results: (A-R) header
field to some filter where it is used together with other input. As
a receiver, it up to me to decide how I am going to use all
that. From an OpenDKIM perspective, there is something missing which
we are trying to address through a policy feature. We will need more
information than the pass/fail and the A-R header inserted by the
milter. With the relationship, we can identify the different types
of mail traffic and apply different local policies.

>What dangers come from not being able to prove it? I

I would not label it as a danger. People will use heuristics. The
problem when we are not able to prove it is that we can end up
rejecting valid mail.

>Why AUID rather than SDID?

I suggested AUID instead of SDID as there's also a local-part for the
address. The choice can be user-configurable. As the list-id is not
always where we have the public key in DNS, we cannot use it as the SDID.

>How will this enable whitelisting or scoring that cannot current be
>performed? Currently an SDID develops a performance history, good or
>bad, no matter what it is "tied to". How does this added feature change that?

There are different ways to use the SDID. We can use it to gather
performance information, good or bad, and do scoring. There's the
dkimreputation feature in OpenDKIM. We can do whitelisting
already. But it is not enough for OpenDKIM policy stuff. That's
where I would like to use it.

>The presence of List-* or Resent- fields declares that a message has
>gone through particular re-submission. So your proposal is not
>needed for the purpose you just stated. I suspect you mean
>something deeper that cannot already be discerned from their presence?

Yes, they do declare that if they are being signed. But there is no
way to say what the identifier, SDID for example, is for. There is a
sendermacro feature in OpenDKIM where we can select the address for
DKIM signing. OpenDKIM don't have a mechanism to pass that
information though. The proposal I wrote is more of an idea. There
are a lot of missing pieces and there's still the security angle to consider.

>This opens the essential question of whether there is a basis for
>believing that receivers will adopt this? Stated more pedantically,
>what is the receive-side value proposition and which receivers find
>it compelling and why?

This is an experiment. It will be marked as "for future release" if
the code is accepted. I seriously don't know whether receivers will
adopt this and I won't propose that the feature be enabled by default
as it is non-standard.

Regards,
-sm
Received on Sat Oct 17 2009 - 20:55:11 PST