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
