ietf-mailsig
[Top] [All Lists]

Re: DKIM KEY SSP Override Option [was Re: The cost of choices]

2005-07-30 09:56:41

Hector Santos wrote:

----- Original Message -----
From: "Jim Fenton" <fenton(_at_)cisco(_dot_)com>

Jim, question.

Why isn't the SSP part of the selector key TXT record?
Hector,

In the absence of a signature, there's no selector name to use.  If
there is a signature for the origination address which fails
verification but for which it's possible to retrieve the key record, I
suppose that putting the signing policy in key records as well would
save a lookup, but it would be a small savings.  A policy change would
then require that all key records change as well, and that seems
burdensome and prone to inconsistency.

Well,  I hear you but I am not among those who believe overrhead potential
should be taken so lightly.  We have even scratched the surface yet.   I am
a firm believer of the CBV and SPF concepts and our package includes it as
part of AVS suite.  Yet I understood fully in a wide deployment, the DNS and
call back chaos potential can not be under estimated.  So we do want to we
can to minimize all need to do a SPF and CBV and we do our upmost to avoid
any payload transfer.

DKIM is a payload solution so inherently it increases bandwidth, so
comparably, an additional DNS check may be miniscule in the total sum of the
transaction.

Keep in mind DNS lookups does fail some times so the less you have to call
it, the better.
You have a very good point; it deserves further discussion. It would be fairly straightforward to put an optional policy statement in the key record, and save the other lookup. But I have some problem with per-key policies; see below.

Does it make sense to have it as an override?
I'm not sure what you mean by an override.

The domain policy may indicate one SSP and the selector key policy has
another SSP.   The domain SSP is the default, the key SSP is the override.

I might want to have a relaxed domain signing policy, but for a specific key
I might want an exclusive signing policy.  The override is an option.

Or vice versa,  the domain has an exclusive policy, the key is relaxed.
SSP comes into play when there isn't a valid signature for the origination address. When a signature isn't valid, you can't trust anything about it. So one can't infer a different policy (particularly if it is more relaxed) by the presence of an invalid key that uses a particular selector.

When the business MDA receives the mail, it verifies the signature and it
could stop there, but in my opinion, it should see if the selector policy to
see what the SSP is.  It might be NEVER (o=.)
If it's NEVER, there shouldn't be a selector to retrieve, correct? So the signature should not verify, and the policy of "do SSP if there isn't a valid signature for the origination address" still works.

If the MDA is a mailing list which does another level of distribution
signing, then I believe it needs to see if the FROM: address allows for 3rd
party signing.

Lets put it this way:  I would LIKE for it to check for 3rd party signing
because this is the only way I can have some level of confidence that my
email address will not be exploited by that server.
It may make some sense for a third party signer to check to see whether the origination address allows third party signatures before it adds one, yes. Others have noted, however, that known mailing lists have their own value; sometimes recipients would be as interested (or perhaps more interested) in the mailing list signature, because they value receiving all messages from the list.

To me, it is pretty clear, all 3rd party signers and verifiers need to
investigate the SSP of the original sender.
The problem is that an attacker could be posing as a third-party signer, so the recipient can't depend on any third-party signer actually doing any checks.

-Jim

<Prev in Thread] Current Thread [Next in Thread>