ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] linkage between "originator" and "handling agent"

2005-08-16 20:53:57
----- Original Message -----
From: "Earl Hood" <earl(_at_)earlhood(_dot_)com>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)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
Policy attribute?

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

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.

Agreed.

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

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
determination logic.

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
MUA/MFA automation.

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
Tracking concept.


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.

Agreed.

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.

Agreed.

I would like to know what Eric Allman thinks about all this.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com


_______________________________________________
ietf-dkim mailing list
http://dkim.org

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