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
