mail-vet-discuss
[Top] [All Lists]

Re: [mail-vet-discuss] DKIM dependency

2008-10-08 18:50:46


Murray S. Kucherawy wrote:
Dave CROCKER wrote:
Folks should be explicit about making and documenting this choice:

      Is the information being provided about DKIM or about a validated 
domain 
name?
  

We want to validate the domain name.  How that's done is less important, 
although choosing something easily adopted is certainly preferable.  

I hope the latter statement represents group consensus.

As for the former, I suspect, strictly speaking, this mailing list is about 
reporting the results of validation, rather than actually doing it...

Rather than being petty nit-picking, I think it's important to use language 
that 
accurately and precisely states where this mechanism is in a processing 
sequence 
and what exact function it is performing (and why).


That DKIM seems the most obvious approach doesn't mean it's the only 
one, or that it's the one this draft needs to recommend as a SHOULD.

Reality forces once to acknowledge that there are other domain name validation 
methods widely extant.  I doubt there is any good technical or operational 
reason to exclude them.  Rather, I suspect there are good operational reasons 
to 
*in*clude them.


I'd be fine being generic and saying the administrator has to find some 
way to secure that channel.  In fact, I think that's where we are now.  
However, I suspect there are as many ways to do that as there are e-mail 
architectures out there.  Thus, saying the channel SHOULD be secured and 
then simply suggesting DKIM as one way to do so would be sufficient for me.

+1


The remark about not complicating mail systems any further seems to be 
where I'm focusing.  Given that any participant in this system will need 
to know which MTAs it can trust, any solution will have that problem to 
solve.  I don't think any of the proposed solutions I've seen are more 
complicated than the next.  So how do we go about picking one?

I think this is a question of defining and labeling trust boundaries and 
deciding how to use them for this mechanism.

This is about the authserv-id field, isn't it?

The discussion in 2.3 probably needs to be a bit more precise and extensive.  I 
suspect that "refers to the authenticating service" is not quite right, while 
"identifier is guaranteed by the mail administrative domain that generates it" 
is, albeit without making clear that this means it defines a trust domain.

The current document pretty much starts with the notation and build up to an 
explanation of semantics.  I'm wondering whether there should not, in addition, 
be an earlier discussion of the trust environment that permits operating this 
mechanism.  (I think the DKIM lacked this sort of service definition and that 
we 
have sometimes been hindered by confusion resulting from the lack.)  While the 
very first sentence of the Introduction sets the stage for the mechanism, I 
think the rest of the scenery needs more explication than is provided.

--->
The Authentication-Results header fields permits a domain name validation 
mechanism to communicate its output to a separate domain name reputation 
(assessment) mechanism. These mechanisms MUST operate within a unified trust 
boundary that defines an Administrative Management Domain (ADMD). An ADMD 
contains one or more entities that perform validation and generate the field 
and 
one or more that consume it for some type of assessment.  The field contains no 
integrity or validation mechanism of its own, so its presence must be trusted 
implicitly.  Hence, use of the field depends upon ensuring that mail entering 
the ADMD and having versions of the field claiming to be valid within this 
domain removed, so that occurrences of such fields can be trusted by consumers.

The authserv-id can be used to label an entire ADMD or a specific validation 
engine within an ADMD. Choice of labeling schemes is left as an operational 
choice.
<---

I also suggest reviewing the document for opportunities to assert normative 
requirements in normative language.

For example:

    " The uniqueness of the identifier is
    guaranteed"

       is -> MUST be

    "Additional result codes (extension results) may be defined"

       may -> might

d/


-- 

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

<Prev in Thread] Current Thread [Next in Thread>