ietf-dkim
[Top] [All Lists]

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

2005-08-29 02:50:32
On Sun, 2005-08-28 at 18:44 -0700, Dave Crocker wrote:

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.


I will attempt to provide a more coherent presentation of the concept in
the draft revision as I suggested.


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


This has to do with being able to recognize a prior correspondent
without the use of complex and problematic authorizations.  This would
work in conjunction with a scheme that detects when a message was not
sent directly to the recipient.  There would also be a field that adds a
type of account-cookie or domain-cookie that provides a basis for
several features.

These features include replay abuse abatement, but also provides a basis
that could be used in conjunction with opportunistic identifications
where the MUA would bind this cookie with the signing-domain and keyed
off of the mailbox-domain, mailbox-address or the pretty-name.  The
signing header could indicate the amount of the binding needed to
isolate or resolve to domain assured originator identifiers.


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


Inclusion of the revocation-identifier as described.  Adding binding
recommendations would reduce user interaction required to support the
scheme.  In some cases, the bindings could be automated.


"Opportunistic identification" sounds fascinating.

a) where is is defined? and

Consider the strategy used with SSH for self signed certificates.  DKIM
could be considered a type of self-signed certificate.
   
The elemental basis of this identification has been defined in: 
http://www.ietf.org/internet-drafts/draft-otis-mass-reputation-01.txt

The title of this draft is not about implementing a reputation mechanism
or communicating with a reputation service.  This draft's title refers
to concerns regarding protection of the sending-domain's reputation
through controls that must be available to abate abuse.  Abuse is a real
threat.  I would hope abating replay abuse for example is not seen out
of scope.  The ability to bind opaque signed identifiers to prevent
targeted spoofing would be another feature offered.


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


This question seems rather circular for a discussion of general goals
attempting to define a minimal set of essential elements to defend
against expected threats.  Although SSP was offered as a solution, does
that exclude other equivalent or superior methods?

What is the goal that SSP achieves?

How does SSP resolve:
 - DoS issues?
 - replay abuse?
 - inter-domain spoofing issues?
 - third-party signing issues?
 - increased overheads?


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 disagree.  It would be like saying DKIM prevents forgery (provided the
first name is correct and was not endorsed by a third-party).  DKIM may
allow the association of mailbox-domains with a verified signature.
This does not prevent mailbox-address forgery nor would DKIM
authenticate the mailbox-address.


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.


A claim regarding a statement about forgery immediately followed by a
statement that DKIM authenticates headers is misleading to say the
least.  With DKIM, anyone could provide a falsified RFC2822.From address
and provide 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 agent will treat the message as an error.


A valid signature may not be related to the RFC2822.From domain.  


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


These two requirements do not represent forgery protection where even
describing this as narrowing the hole permitting forgery is misleading.
DKIM does not authenticate the RFC2822.From header.  Only the signature
is verified.

Attempts may be made to bind this signature to some mailbox-domain.
Preventing third-party signatures will disrupt email delivery in many
cases.  Selectively preventing third-party signatures will carry a high
overhead.  Even when third-party signatures are excluded:
 - inter-domain falsification of the RFC2822.From remains possible
 - an unseen Sender-header may have been applied
 - only the pretty names may be visible



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.


Why is the term forgery in the charter?  The concept of forgery is
related to falsifying the identity of the author as understood by the
recipient.  SSP is about authorizing a possibly unseen _mailbox-domain_
only when specific domain-wide assertions are applied and then checked.

Even when SSP is applied to a visual mailbox-domain, the recipient will
not know the number of possible domains still able to forge this
identity.  Without per-user keys, it would be impossible to make
assurances related to the author, which should be out of scope for DKIM.
So should the concept of forgery, as DKIM does not assure or
authenticate the purported originator mailbox-address.  Such assurances
are clearly suited for S/MIME or OpenPGP.



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?


Perhaps I need to understand how you view the goals of the charter.
What is meant by the authentication of headers as related to forgery?  



"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?


This would depend upon how the recipient defends resources and would be
related to permissions derived from the accountable domain established
by 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?


This would be with respect to the handling and support of third-party
signature assertions.


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


I have been suggesting a different approach instead of SSP.  A logical
breakdown of a threat analysis would be easier had the charter been
clearer about the goals.  The current charter seems to miss the mark.
You have not commented upon the suggested changes to the charter.  Is
this because you feel there is no benefit derived from establishing an
accountable domain?



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 shavingsp refer to tree-walking.


Review section 5 of the SSP draft.


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


The details have not been provided by Eric yet.  He would like to add a
list of permitted domains.  


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


This question seems to avoid the discussion of general goals.  Part of a
process attempting to define a minimal set of essential elements to
defend against expected threats.  When the conversation is specifically
related to dealing with threats, it would seem you want to not consider
alternatives because that is not related to DKIM or SSP.  Do you see how
that is circular?


-Doug

_______________________________________________
ietf-dkim mailing list
http://dkim.org