On Tue, 2006-12-26 at 11:21 -0500, DKIM Chair wrote: > In discussions with the IESG to sort through their "discuss" comments, > I had a talk with Lisa Dusseault, and she had one point that I want to > bring back to the mailing list: I don't think we considered, in our > discussions of multiple signatures, multiple *linked* signatures, which > could work TOGETHER to convey information, and the protocol doesn't > allow that sort of thing. The way dkim-base is set up, I don't think > this could easily be added as an extension, and it'd be a significant > change at this point. Here's the concept: > * Signer puts on two signatures (maybe as two header records, maybe as > one that contains two sigs).
There is a situation that could lead to a DoS related to multiple signatures. This problem would be in conjunction with a discovery process checking associations of an email-address with that of a list of signatures contained within a message. The signature itself offers little assistance in determining which email-address induced the signature when the signing-domain differs from that of the email-address domain. Lack of assistance in a signature selection process in this case is due to a limitation placed upon the 'i=' syntax. This syntax can be upwardly changed to allow explicit associations asserted between an email-address-in-question and any signature. It will remain apparent when the email-address domain and the signing-domain differ. With older implementations, such a signature will be invalid and ignored. The basis for the 'i=' syntax limitation assumes policy blocks messages not signed by a parent domain. This concept is based upon visual recognition and remains highly flawed for many reasons. Once MUA "recognition" of email-addresses based on Address-Books or trusted lists is used, then extending the 'i=' syntax makes a great deal of sense. Having the MUA preform verification also overcomes requiring a trust relationship between the MDA and the MUA, while also thwarting common look-alike attacks. > * One of the signatures has minimal scope, maybe signing only "from:", > with l=0. > * The other signature covers as much of the message as possible... > most headers, all the body. > * The two signatures work together. If one verifies and the other > doesn't, the verifier can consider what was changed in the message, > and possibly use that information to deal with mailing list > modifications or whatnot. There is also the body hash that can provide a similar function. The use of multiple signature will likely occur, but not for this reason. At least there should not be any valid reason for using the 'l=0' parameter. > One way this might be used is to have one signature that covers the > subject header and one that doesn't, to allow the verifier to detect a > subject change and decide whether it's OK. As the spec is now, the > verifier would just find the one signature (that doesn't cover the > subject) that works, and use that, not considering the other. A change to the limitations on the 'i=' syntax could clarify the specific role of the signature, and prevent various DoS exploits that might attempt to overload the resource intensive validation process. An 'i=' syntax change would be beneficial when validations are limited to "recognized" email-addresses. Such a change would limit the number of bogus signatures checked. As it is now, any or all signatures would need to be evaluated for a possible relationship. Header ordering should not be assumed. This issue will prove more significant when the MUA or MDA is used to annotate "recognized" messages. Annotation is the only method where recipients are offered protection by DKIM. Allowing the email-address domain and the signing-domain to differ also retains the normal use of email. Without there being any correlation between the signing-domain and the transmitting entity, abuse-reporting will be far less useful. Before DKIM improves upon email integrity, an ability to associate various email-originating domain with that of the signing-domain still needs to be developed. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
