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

From: Dave CROCKER <[email-masked]>
Date: Wed, 04 May 2011 10:01:57 -0700

Folks,
\
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.

There are two continuing threads of other, technical dissatisfaction being 
expressed that are based on fundamental misunderstandings of protocol design 
concepts.  The discussion on Wikipedia looks pretty good, for background:

    <http://en.wikipedia.org/wiki/Network_protocol#A_basis_for_protocol_design>

The easy misunderstanding is about the basic difference between software design 
and protocol design.  When a discussion is about a protocol specification, 
reference to the vagaries of software implementers' choices means that the 
discussion is no longer about the protocol.

A protocol is a contract between two or more sides of an exchange.  The contract 
needs to be extremely precise so that all sides know exactly what is required 
and what is meant.  This includes semantics, syntax, and rules of exchange. 
Semantics means all of the meaning, not just the meaning of individual fields. 
And it means inputs and outputs.

That an implementer might choose to use fields creatively is their choice -- and 
might even be useful -- but it goes beyond the protocol specification. 
Implmenters can choose to combine specifications, implement only parts of 
specification, or create additional functionality.  This is all well and good, 
but it is an entirely separate exercise from the details a specific protocol.

As for protocol layering, this is merely the standard construct of design 
"divide and conquor" with attendant information hiding outside of a layer.  That 
software might have access to information hidden from a particular layern is 
sometimes useful, but it means that the software is going beyond the 
specification of that layer.

Apparently the distinction between "payload" versus "overhead" is proving 
challenging for some folk.  The logical extension of the view that the recipient 
at one layer has access to the information below its layer means that a MIME 
module must automatically and always has access to the IP and ethernet headers 
of the data that contained the MIME.  In terms of formal protocol specification, 
it doesn't.

Payload is what's handed to the next layer up.  Everything else is overhead for 
getting work done at the current layer.  This distinction is basic to the 
concept of design layering and the attendant information hiding.  Without it, 
there is no information discipline in the design of protocols.  Spaghetti 
protocol design is even worse than spaghetti software.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 4 May 2011 13:56:03 -0400

On Wednesday, May 04, 2011 01:01:57 PM Dave CROCKER wrote:
> 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.

If you're looking for consensus, count me in.  I don't think it was progress.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Thu, 05 May 2011 03:48:12 -0700

> And it means inputs and outputs.
DKIM is unable to _only_ consider signature confirmation and not also
expect existing email agents to not also adopt DKIM's unusual header
selection methods retro-actively. To be compatible with existing email
infrastructure and transparent to the fullest extent possible, one
can not expect new supporting infrastructure or modified clients;
This can *only* be achieved by some mandatory test within the Verifier.

-Doug

---

From: Barry Leiba <[email-masked]>
Date: Thu, 5 May 2011 16:24:00 -0400

Dave says...
> 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.

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.  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.

Barry, as participant

---

From: Douglas Otis <[email-masked]>
Date: Thu, 05 May 2011 14:31:38 -0700

On 5/5/11 1:24 PM, Barry Leiba wrote:
>> re-opening
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.
> 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
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

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 06 May 2011 14:28:04 +0100

> trustworthy; whether a failed signature can nonetheless provide useful

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 :-( .

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 06 May 2011 10:28:34 -0700

On 5/6/11 6:28 AM, Charles Lindsey wrote:
> On Thu, 05 May 2011 21:24:00 +0100, Barry Leiba<[email-masked]>
> wrote:
>> Doug says...
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