On Wed, Jun 11, 2014 at 3:22 PM, John Levine <[email protected]> wrote:
> Someone sends off a message to a mailing list with the two DKIM > signatures and DKIM-Delegate. Someone else, perhaps a list > subscriber, notes that the weaker signature doesn't cover the body, so > he replaces the body with nose enlargement spam and blasts it out. > Recipient MTAs which haven't been updated since 2014 and don't know > about DKIM-Delegate see the weak but valid signature and since the > signer has a generally good reputation, delivers it. Ugh. > Right, that's the "considerable latitude" that's already mentioned in the draft. The "x=" is the current protection against that sort of abuse. It's not much, but it's what we've thought of so far. The alternative is to use an "l=" that is the length of the original rather than 0, which constrains the abuse considerably but might reduce the likelihood of this working. > This hasn't been a problem before. Although you've always been > allowed to use weak signatures, there's been no advantage to doing so, > so nobody did. Now you do, but with new semantics that you shouldn't > pay much (any?) attention to that signature unless it's paired with > the forwarder's. One could make an argument that it's not technically > a semantic change to DKIM (indeed, Dave just did), but in practical > terms, it is likely to interact poorly with existing unupgraded > software, so I'd want a version bump so that the old software ignores > the special purpose signature. > I see your point, though it seems strange to do a version bump when that's really the only change to the bits on the wire, and the only real change then is how the signatures are interpreted; syntax vs. semantics. > Bonus question: why put the author domain and target domain fields in > a new header rather than just addding ddd=<author> and > ddt=<forwarders> to the signature header? > Originally it was done as a separate tag, but that meant changing DKIM in some way even if it means registering a new tag that some/most will just ignore. Using a separate header field keeps DKIM itself pristine, and just builds on top of it. Would reverting to a tag method obviate the need for a version bump? -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
