ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Protocol layering / Software vs. Protocol

2011-05-05 16:47:16
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