Michael Thomas wrote: >> Maybe it's me that's messed up. Using Dave's operator terminology, I >> thought that meant the entity running the MTA (e.g. the ISP or domain >> host).
Yes, I believe that matches the way I have been defining the term. > I think you're using it the same way as Dave, but your message doesn't make > sense to me because there may not even be an "operator domain" in the path Just in case there is confusion: We all need to be careful with the word "domain". (I'm not saying Michael isn't, but rather am noting a concern for this thread and beyond, just in case the usage issues are not clear for everyone.) When talking about an Administrative Management Domain (ADMD), its associated domain name might not be part of the issue. In fact, that is exactly the distinction between using sub-domain names, for outsourced signing, versus creating some sort of publicly visible delegation mechanism, such as DSD. With sub-domain names, the signing domain (d=) can be the domain name of the author. With delegated domains, the signing domain is associated directly with the outsourcing agent, but then is linked back to the author domain. As I understand it, the intent is to say who actually did the signing, but then request that their reputation not be used for evaluation, but rather that the reputation of the author's domain be used. I believe the above description of the different approaches is accurate and that it should make clear that a "delegation" mechanism that is visible to the recipient entails an entirely new layer of indirections. Hence, additional complexity, additional overhead, and additional risk. If you want the reputation of the author's domain to be used for assessment, then sign with the author's domain. If you want the reputation of an operator's domain to be used, then sign with that operator's domain. Creating a mechanism that specifies "authorization" of another domain (or, rather, a mechanism that certifies an indirect reference) is entirely unnecessary. I keep coming back to a simple request and haven't seem clear answers: DSD, and the like, create a mechanism. As nearly as I can tell, this additional mechanism does not define new functionality. Hence the arguments in its favor need to be clearly and compellingly stated. My request is that this be done. The arguments that I believe have been made, so far, are: 1. An additional delegation mechanism removes the "need" for passing around security information 2. An additional delegation mechanism is more likely to be kept up-to-date. If there are additional assertions, folks should make them and justify them. As for these two, here -- Passing Around Security Information: When there is a trust relationship between two independent organizations, there will necessarily be some trust/security-related information passed around. The details of what information and how it is exchanged will vary, but in all cases there will be some sensitive information exchanged. . There appears to be a view held by some that passwords are a special deal, but I will claim they aren't. The difficult aspect to such an exchange is authenticating the participants. I will claim that once this is done, adding privacy is a relatively minor concern. The technology and practices for sharing secret information between consenting participants is far too well established for anyone to believe that it imposes particularly onerous issues. Rather, I'll claim that *any* information depending upon the trust relationship entails the same risk. In other words, the primary issue is whether the parties do trust each other and do believe that the information they get from each other is valid (authentic). By that measure, the particulars of delegation are not the issue. Rather the issue is the mere fact of transactions that depend on the trust relationship. Keeping delegation information up to date: Sub-domains are well-established constructs. It is certainly true that many kinds of domain name records are not kept up to date. However the tools for doing this administration are, at least, well established. What is not clear is why anyone believe that an additional mechanism for indirect specification will not be just as bad? To the above issues, I'll add one more minor topic: Efficiency: An extra mechanism is an extra mechanism. As John Levine points out it is inventing a new mapping, with all the risk attendant to inventing anything. In this, case, however, what is being invented is a new security layer. This ought to worry folks, given the demonstrated difficulties in getting new security mechanisms successfully validated, deployed and used. Since the mechanism has a remarkable similarity to the path registration schemes of recent focus, we should also worry about the administrative and operational impact that the new mechanism are likely to share with these. This extra mechanism also entails additional effort during validation. More to administer; more to query; more to correlate. As a rule, all this extra work ought to be required to provide extremely significant benefit, over the alternative of using existing mechanisms. It doesn't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
