-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of John R. Levine
Sent: Wednesday, October 13, 2010 10:49 PM
To: dcrocker(_at_)bbiw(_dot_)net
Cc: DKIM List
Subject: Re: [ietf-dkim] detecting header mutations after signing
What you are calling for would be good to have. It should be done.
Just not in the signing spec.
Correct me if I'm wrong, but I hear you saying that if one creates or
verifies the DKIM signature on a message, one should also do the double
header check somewhere in the mail processing path, but rather than
saying so in the spec, it'll just be our private bit of folklore.
I'm completely okay with providing informative guidance to signers and
verifiers, or even to receivers and MUAs, maybe even right in the bis document.
But once it becomes normative, and especially if we want to put a MUST in
there, we're requiring the work of enforcing the terms of a non-DKIM RFC into
DKIM. Any way you slice it, that just sounds like bad engineering to me.
If we accept the model that DKIM is a layer that sits on top of the mail layer
(and by that I mean RFC5322; SMTP is a layer below that even), then what
crosses the layer boundary should only be valid, in the same way that only
valid IP packets get passed up to the TCP layer, or only valid and sequenced
TCP packet payloads make it up into a socket's read buffer, or only a valid
SMTP command sequence can cause something to land in your inbox. The mail
layer shouldn't pass crap upwards; and in this case that means an MTA shouldn't
invoke a DKIM library/function/whatever unless the data it's about to pass
across that line is known to be valid for that transition. The mail layer is
where RFC5322 is implemented, so it has the code to do what you called the full
body cavity search already, and so any lightweight header counting is thus by
definition not only cheap, but actually redundant.
It should be perfectly fine to say DKIM expects valid input, for whatever
definition of that we want to invent, and also state that handing it anything
else has either undefined results or specific bad results. I can point out
dozens of UNIX man pages that say the same thing. It's not a new idea.
In a C program, if I ask you to hand me a valid string, I'm saying something
that has a specific, unambiguous, well-documented meaning. If despite that you
hand me something that may or may not be a valid string, it's unreasonable for
you to expect me or other possible handlers of that data to do something valid
or safe with it every time. Indeed, the result could often be catastrophic.
That MUAs or post-DKIM filtering agents might make weak, lazy or foolish
rendering decisions is certainly unfortunate, perhaps even terrible, but I'm
not convinced that all (or any) of the layers below that need to do normative
things that compensate for, accommodate, or fix everything that might make it
up that far, protecting them from themselves, only to have them come up with
yet another new way to be vulnerable later.
As I said in another message, I realize once you're actually writing an
application to do all of this then the interface lines can get quite mushy.
But I don't believe the IETF should be in the business of producing standards
track protocol specifications that define interface lines which are
intentionally mushy.
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html