[ietf-dkim] linkage between "originator" and "handling agent"
hsantos at santronics.com
Tue Aug 16 20:45:52 PDT 2005
----- Original Message -----
From: "Earl Hood" <earl at earlhood.com>
To: "Hector Santos" <hsantos at santronics.com>
> It should be reject. I think the FAIL rows should be reject across the
> board. Policies should not allow wiggle room for failed signatures,
> otherwise attackers will exploit them (some leniency may be doable,
> see below).
I see your point. Yes, Failure Policies. I like it.
I was thinking how a SSL client (e.g., Browser) may work today ergonomically
where it will provide, atleast 3 pieces of inforamtion:
- Certificate Invalid
- Certification Valid, does not match domain
- Certificate Expired
Could this mean DKIM could use an domain defined "Action to Take" Rejection
- Reject if Hashing fails
- Reject if Domain does not match
- Reject if Signature Key Expires
I would not suggest this for "Acceptance policies." That will opens up more
>> But what if there is no PUBLIC KEY? Then I think it would
>> REJECTS instead of WARNING, because it doesn't make sense to
>> have a SSP record but not a KEY record.
I was rethinking this. I believe you and I touched based on this (in
IETF-MAILSIG) in regards to ISP hosting domains and providing 3rd party DKIM
signing services. For example, we envisioned a TOS might be required
between the domain holder and ISP vendor. The domain may not want any
signing done on his behalf.
In other words, the DOMAIN uses a SSP record to communicate with the ISP
signer or any other signers in the path of the message. I can see why now
"NEUTRAL" (optional, 3rd party signing allowed) was used by the spec
This brings up another point about a missing policy: NONE
NONE = says NO SIGNING is expected.
Hmmm, no, a WEAK (optional signing, no 3rd party) can handle this. Right?
> > Or could this be a DNS lookup failure issue?
> If DNS lookup is failing, the message should be requeued for later
> processing, or if verification is done during an SMTP session,
> a temporary reject can be indicating so sender can resend later.
Which further complicate things as far as retry frequencies and final
If its SMTP level DKIM processing, does this mean a 45x response is more
appropiate? We don't want a DNS lookup failure to be a loophole for
acceptance for delayed processing.
And if this is a POST SMTP process, doe the failure mean a BOUNCE should
take place as required by SMTP?
>> Per SSP specification, a domain with no SSP DNS record, defaults
>> to a NEUTRAL policy.
> I do not like this since attackers can exploit domains that have
> not adopted DKIM. If no record is present, a signature on a
> message should be considered suspicious. Rejection should be
> acceptable behavior in this case, and at a minimun a warning.
Reject if no public key. Warn otherwise. Right?
> And any leniency leaves room for attackers to exploit. Warning may
> be acceptable, but how the warning is presented to the recipient of
> the message is crucial.
Right. I should note, the interest is in establishing the required
consistency and understanding where there could otherwise be threats or
holes using Accept (ok), Reject (not Ok), Warn (I don't know). Any other
similar terminology can be used and it may or not may be the basis for
feading a reader client information.
This brings up another point:
I think DKIM should prepare itself for presenting structure result
information to MUA and MFA (Mail Filtering Agents) software. I didn't read
all the various statements about the Authentication-Results: header, but
there wasn't a clear structured layout of how results can be written for
If we expect to help future MUA/MFAs, then we should be defining these now.
> Some signature failure conditions should always indicate rejection:
> Key expiration, key revocation, non-existent public key, malformed
> signature data. This is why knowing why a signature failed is
> important. If everything looks good, but the hashes do not match,
> then outright rejection may not be completely desirable.
Right. But I have a question:
Why is mail (body) integrity important when it seems DKIM is more concern
about which domain signed the message?
In the old fidonet days, we used a strong Dupe Checking logic using
Message-ID: lines. Technically, we don't need the body at all if we use a
strong Message-ID: requirement representation for the message signing.
I am just winging it now:
1) Signing process includes Message-ID:
2) Verifier records Message-ID:
3) If another message arrives with Message-ID, then you have
tracking/dupe checking so its not possible to replay the
same signed header.
Off hand, I don't see a replay attack using a strong Message-ID: Verifier
> In this case, the SSP could determine what the verifier should do
> since the behavior should be consistent. I.e. If SSP will not
> support failure policies, then all verifiers should treat a fail
> condition the same (to avoid exploitation).
Yes, I think this is good idea. Failure Policies and possible also optional
"Reporting Policy" would be EXTREMELY useful for a feedback system.
> If SSP allows failure policy definitions, some domains may be willing
> to live with hash not equal failure if a warning is provided (since
> the domain does not want to prevent complete rejection of email).
> While others may want a stricter policy.
> The forwarding/mailing-list scenario does complicate things. Hence,
> some domains may support a warning for hash failure during early
> deployment, but will hope forwarding/mailing-list services will change
> so rejection can be done.
So its important to be able to detect a hash failure vs a signing failure?
> > If we were able to detect a HASHING failure, for example, the "virtual"
> > warning/logging (asssesment) might be:
> > "WARNING: This message failed a DKIM hashing error."
> Of course, a message like to a receipient will just confuse them.
> Something more useful will need to be communicated to a recipient.
Just pointing out if its possible to detect a hash error vs a overall
signing error. Does it hurt to expose the SHA1 hashing base64 along with
the final signature? Or is this too much information for a crypto hacker?
> All verification behavior must be consistent in how successes and
> failures are handled. If variability in behavior is determined to
> be essential (especially during early DKIM adoption) such behavior
> should be controled by SSP. If verifiers are allowed discretion on
> how to treat things, it opens up things to exploitation.
I would like to know what Eric Allman thinks about all this.
Hector Santos, Santronics Software, Inc.
More information about the ietf-dkim