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