[ietf-dkim] Purpose and sequence for DKIM specification and deployment

[Dave Crocker]

Doug,

>>>Your list does not offer the possibility of establishing
>>>opportunistic identity schemes that could based upon the selective
>>>binding of signed message identifiers retained locally.  
>>
>>1. I am pretty sure that I have no idea what you are describing.
> 
> This has been discussed on the list.  I will attempt to describe this in
> an update of the mass-rep draft.

1. Since I've been reading the list rather closely, there is some chance that I 
am not the only one who did not understand what you were talking about.

2. If the issue has to do with reputation, it is out of scope for DKIM.

3. What changes you are suggesting, if any, for any of the DKIM documents, 
existing or needed?


>   With respect to offering
> protection from those attempting to forge the author of a prior
> correspondence, opportunistic identification offers _better_ protections
> than that achieved using domain-wide authorization schemes.

"Opportunistic identification" sounds facinating.

a) where is is defined? and

b) it sounds like a different scheme than DKIM is using, so I am not clear how 
it is relevant to the DKIM discussion.


> Domain authorization mechanisms should not make anti-forgery claims,
> despite the misleading charter goal.  A domain is never the author of a
> message.  

Any claims at prevention or detection of misbehavior certainly need to be 
clearly explained.  However I do not believe there is any DKIM documentation 
that claims that a domain is the author of a message.

I believe the claim regarding the DKIM bases's utility against forgery is that 
an author attempting to assert an rfc2822.From address that has a domain name 
for which the author is not authorized will not be able to generate a valid DKIM 
signature.

If the domain SSP requires signatures on all messages and an unauthorized author 
asserts the From address for the domain but does not sign the message, then the 
validating aggent will treat the message as an error.

Both of these serve to close (or at least narrow) the hole that permits forgery 
of rfc2822.From addresses.


Nor would a message being from an authorized domain assure the
> recipient that forgery has been prevented.  Secondly, the circuitous
> matrix of information involved in such a mailbox-domain authorization
> approach would be difficult to convey to the recipient as the basis for
> acceptance.  

So it is probably good that the DKIM working group effort is not targeting user 
interface issues needed to communicate identity validation to the user.


>>>This can work in conjunction with a host name as was done with the
>>>HELO.
>>
>>It can work in conjunction with lots of things.  Are you suggesting
>>changes to the text I wrote?  To the specifications?  To the charter?
> 
> The text within the charter does not describe how the domain is
> determined. 

"Determined"?  Do you mean chosen by the signer or found by the verifier?  The 
former is outside the scope of our work, relying on something like "whatever the 
signer believes they should use", and the latter is from the signature field.

So what do you mean?


  In the case where the assertion is based upon a host name,
> this would provide direct authorizations which can be immediately
> applied to the server, irrespective of any message header.  Immediate

"Host name"?  DKIM uses the term "domain name" and does not constrain it to a 
host name.

"Applied to the server"?  What does this mean and how is it relevant to DKIM?


> In the case where the domain is obtained from a purported originating
> mailbox-domain, authorizations are indirect and may be unexpectedly
> disruptive or risky when inconsistently applied.  

Disruptive in what way?  Risky in what way?

How are you suggesting that the DKIM threat analysis, charter or specifications 
be changed?


>>>There would be an inordinately high overhead associated with attempts to
>>>associate mail-box domain authorizations within third-party signed
>>>messages.
>>
>>What is the "inordinately high overhead" you are referring to?
> 
> Walking up label-trees of all third-party mailbox-domains, where this
> authorization may also be conveyed to a dereferenced domain, represents
> a significant increase in the level of overhead and complexity.  

1. Neither DKIM base nor ssp refer to tree-walking.

2. What does "conveyed to a dereferenced domain" mean?

How does any of your concern apply to DKIM base or SSP?

-- 
 
   d/

  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net