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

[Douglas Otis]

On 5/6/11 6:28 AM, Charles Lindsey wrote:
> On Thu, 05 May 2011 21:24:00 +0100, Barry Leiba<barryleiba at computer.org>
> wrote:
>> 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.
> Not so. As you should know from off-list discussions, that sentence is
> actually mine, though used in a marginally different context than Doug
> used it.
>
> IF there were to be some "mandatory test within the Verifier", then that
> test would be, ipso facto, a part of the protocol and not part of the
> "software system that wraps around it". So your argument was circular :-( .
This sentence was indeed written by Charles.  He is far more eloquent, 
and I wanted to respond but was rushed by other pressing security 
matters.  While we have collaborated in creating something that should 
better clarify DKIM's role, it is my opinion verification requirements 
are better stated as MUST.

Unreliable Assurances are Worse than NONE.

 From the aspect of proper protocol design and layering aspects, proper 
design must not expect consumers of the protocol to second guess the 
validity of the inputs used, especially when these inputs become less 
clear in the process.

SMTP can not be expected to ensure header field ordering, especially 
those defined by DKIM.  The modern version of the message format also 
clearly stipulates which header fields are required not to repeat.  The 
premise used by DKIM in requiring the From header field to be signed, 
incorrectly assumed that by requiring this header field to be included 
in the signature's validation, the particular header field would be 
obvious to subsequent consumers of its output.  This was clearly a 
mistake made by DKIM that MUST BE corrected.

As email transitions into the use of UTF-8, DKIM's role in better 
securing messages becomes even more significant.  As such, it is 
important to embrace the incumbent obligations.  DKIM must not blame 
SMTP or DNS for its failings.

-Doug