ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] a protocol needs a payload

2009-02-18 17:21:35

On Feb 18, 2009, at 4:51 AM, Wietse Venema wrote:

Eliot Lear:

The question one has to ask is broader than inputs and outputs.   
Are each of the protocol elements described in the specification  
clear enough to be understood as to their meaning?  If they are not  
then that is what needs to be clarified.  Regardless, this debate  
about functional programming (which is really what this boils down  
to) is pointless, and you are ossifying a structure around a model  
that you needn't do.  As we have seen many times at the IETF,  
successful specifications are those in which the model can easily  
evolve over time based on circumstances.

This is precisely the case with DKIM, where the AD's and the IESG's  
intent was to walk slowly before we run.  The DKIM specification  
reflects that intent.

Your errata reflect a different intent.

If intelligent people cannot agree on what is the result of a  
protocol, then there is a problem that needs to be fixed.  The  
proposed errata address the problem. The alternative does not.

Eliot makes a good point.  Eloit's errata does less violence to DKIM.   
However, rather than describing the i= value as a being an opaque  
string, when this value within the i= value matches exactly with that  
of some signed header field, it should be safe to assume name  
collision has been avoided which is easily done with DKIM.  Otherwise,  
extensions like ADSP represent little more than a signature mandate  
with little other value.

A rush to create an errata that emasculates the information offered by  
DKIM (without batteries) seems ill advised.  The general goal DKIM's  
charter was to enable detection of domain spoofing.  As such, the d=  
value within the DKIM signature can not be described as opaque to  
achieve this role.  DKIM is not just an exercise of attaching  
cryptographic tokens unrelated to other message content.

Although a DKIM  i= value may include namespace that does not  
reference a valid destination, this namespace is still that of the  
same domain.  Any semblance of accountability requires that DKIM  
ensure a valid signature represents message control by an  
authoritative entity for this domain's namespace.  As a general  
practice, this entity should avoid colliding non-valid and valid  
namespace within the same message, or the i= value might be deceptive.  
In general, DKIM should not sanction deceptive messages.

-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html