[ietf-dkim] Protocol layering / Software vs. Protocol
dotis at mail-abuse.org
Fri May 6 10:28:34 PDT 2011
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>
>> 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.
More information about the ietf-dkim