On 5/5/11 1:24 PM, Barry Leiba wrote:
Dave says...
In terms of working group process, one line of criticism demands
re-opening
(and, apparently, reversing) the work of the Update (RFC 5672). I
haven't seen
any working group consensus to do this nor any industry feedback
indicating this
is necessary. Consequently, attempts to pursue the content of that
work is
entirely out of scope for the current working group effort.
I'll point out that Dave is offering his *opinion* about whether this
is in or out of scope.
I'll provide the chair's judgment on that, as the one who has the task
of determining scope: it's out of scope. We had this discussion back
when we did 5672, and got rough consensus on it. Not unanimity, but
rough consensus. We're not going over that again. 4871bis is, and
should be a merging of 4871 and 5672.
Barry, as chair
Doug says...
This can *only* be achieved by some mandatory test within the Verifier.
Not at all; that's exactly Dave's point in discussing the difference
between the protocol and the software system that wraps around it.
The Verifier is a component that verifies the signature, and that's
all we're defining normatively here. Other parts of the system will
evaluate things whether the verified signature can be relied upon, and
what it can be relied upon for; whether the domain that signed it is
trustworthy; whether a failed signature can nonetheless provide useful
information; and so on.
Providing unreliable assurance is worse than none.
DKIM can not expect other agents, especially those predating DKIM, that
when message acceptance is based upon DKIM PASS from trusted domains
that they must also be aware of bad assumptions made by DKIM. As it
currently stands, DKIM offers PASS for highly deceptive messages having
invalid formats.
A narrow view about what entails a DKIM verified message *MUST* include
what is needed to safely employ its output by subsequent agents. Not
considering likely deceptive forms of a message represents a _truly_
dangerous specification.
The current DKIM introduction states the following:
1. is compatible with the existing email infrastructure and
transparent to the fullest extent possible;
2. requires minimal new infrastructure;
3. can be implemented independently of clients in order to reduce
deployment time;
4. can be deployed incrementally;
5. allows delegation of signing to third parties.
This view expressed as:
"Other parts of the system will evaluate things whether the verified
signature can be relied upon, and what it can be relied upon for;
whether the domain that signed it is trustworthy; whether a failed
signature can nonetheless provide useful information; and so on."
is clearly at odds with points 1, 2, 3, and 4 when this also entails
re-evaluation of message elements already examined by DKIM.
It's reasonable to give non-normative advice, perhaps strong advice,
about what other system components might do in that regard. Most of
that advice should be in the other, informational documents, and some
might even reasonably be here (and some of it is). But it can't be
mandatory.
For DKIM to be trustworthy and not cause greater harm, it MUST confirm
the form of the message is valid. A much simpler task than public key
cryptography easily done simultaneously. It would be negligent and
unreasonable to blame the transport for multiple From header fields when
there are more than one, or their order, or which will be used by
subsequent agents. Why is it reasonable to expect other protocols will
repair DKIM's oversights and bad assumptions? Responsibly respond to
exploits as they are discovered irrespective of the specification's status.
I'll point out what Paul Hoffman had said many times in
earlier discussions: you can't control what the receiver [meaning the
overall system on the verification side] will do... you can only give
it the information.
There is no argument with Paul's statement. Nevertheless, don't excuse
the deceptive nature of bad advice offered by DKIM verification process
when it overlooks both invalid and likely highly deceptive messages.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html