On August 16, 2005 at 23:45, "Hector Santos" wrote:
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
It will help to minimize the set of failures that can be controled
by SSP. I.e. Some failure indications should have a fixed response
behavior, regardless.
For example, key expiration should be reject. Otherwise, you
violate the reason to have an key expiration in the first place.
Note, there is the use case of being able to verifiy "old" messages.
However, this is beyond the scope of DKIM.
Another example: Key revocation should always be reject.
Now, I will admit that some failure indications may be tough to
figure out, but a thorough analysis should be done and good justification
should be provided when a failure behavior can be controled by SSP.
The following is (the start of) a list possible errors that may occur
(excluding SSP checks):
* Malformed DKIM-Signature data (field and tags are not syntactically valid).
* Unsupported DKIM version (v=).
* Unsupported cryptographic signing method (a=).
* Malformed signature data (b=).
* Unsupported canonicalization method (c=).
* Identity entity (i=) not a subdomain of Signer domain (d=).
* Unsupported query method (q=).
* Invalid signature timestamp (t=) (e.g. Time is in the future!)
* Signature expired (x=).
* Malformed DKIM key DNS record (record is not syntactically valid).
* Signer key expired.
* Signer key revoked.
* Key granularity (DNS g=) does not match local part of identity (i=).
* Unsupported key type (DNS k=).
* Signer public key malformed (DNS p=).
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.
I do not like this policy since it opens up to spoofing attacks
(I think).
There were discussions on the real meaning of
"third-party", so that term needs to be clearly
defined so we can be in sync on what 3rd-party means. See
<http://www.mhonarc.org/archive/cgi-bin/mesg.cgi?a=ietf-mailsig&i=200507312310.j6VNAQu21809%40gator.earlhood.com>
and
<http://www.mhonarc.org/archive/cgi-bin/mesg.cgi?a=ietf-mailsig&i=42EDD363.6030702%40cisco.com>
I think it is valuable that the OA has the ability to specify who
can sign on their behalf.
I'm not sure I agree with Jim's definitions, but I can go with whatever
is decided upon. This way we can make sure everyone interprets your
table the same.
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?
When no SSP exists, how can we interpret what the OA intended. We
can't. Therefore, I go with, "what is safest" doctrine. Absence
of SSP should mean absence of any signatures. Otherwise, spoofing
can be done, causing DKIM to be used to exploit non-DKIM entities.
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.
MTAs are designed to deal with temporary failures. I see this as
no different, so I fail to see the concern here.
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.
Yep.
And if this is a POST SMTP process, doe the failure mean a BOUNCE should
take place as required by SMTP?
If the message cannot be processed within the queuing time period
configured. If a system is having DNS problems for that long,
there are other things to worry about then mail delivery and DKIM
verification :)
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?
I'm inclined to reject since warning has user interface aspects
that may be exploitable. A signer should make sure that the signer
public key is available before signing with the corresponding signer
private key.
BTW, if the public key is missing, this may indicate a DNS-based
attack.
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.
A risk here is the communication path between the verifier and the
MUA/MFA. This is where DKIM-aware MUAs will be useful. An AR header
may still be useful, especially when the path to verifier and MUA/MFA
is in a closed, or trusted, system.
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?
Signing the body states, "this is what the content of the message was
when I signed it." Therefore, if someone intercepts and modifies
the content, this modification can be detected. You protect from
man-in-the-middle attacks.
MITM attack can be as simple as just doing a resend of a signed
message you receive. Your message-id cache will only detect if the
resend was sent to addresses handled by the same MTA (or set of MTAs)
but not a resend to other addresses.
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?
Nope. What has been proposed before (and meta-signatures takes a
similiar approach) is that the body hash is provided in the signature
header field, and this is part of the data that is digitally signed.
Therefore, the body hash can be compared directly after the digital
signature verifies.
The following basic steps are done to verify (at the crypto level only):
1. Verify the digital signature: The data signed is probably
limited to the DKIM-Signature field.
2. If (1) passes, verify body hash value in DKIM-Signature
to actual message. Since (1) passes, we can rely on the integrity
of the body hash value.
Note, a digital signature is actually an encrypted hash. The hash
that is part of the digital signature itself is computed on header
field data only (so you have two hashes: the body hash and the
one that is part of the digital signature).
If the digital signature (RSA) verification fails, it should be safe
to always reject. By limiting the data that is actually part of the
digital signature (e.g. only the DKIM-Signature field), you minimize
the problems of non-malicious data mutation, so failure at this level
may be a strong indication of something fishy going on.
Side Note:
I'm not sure if you can reliably determine if signature failure is
due to someone carefully munging the digital signature data itself
vs mutating the data that was signed. Maybe someone with detailed
crypto (RSA) knowledge can tell us.
If the digital signature (RSA) verification passes, but the body
hash fails to match, here is where an SSP for (hash) failures could
specify warn or reject.
--ewh
_______________________________________________
ietf-dkim mailing list
http://dkim.org