In message <5B9A4046A1CB9ECDF6B77ACC@xxxxxxxxxxxxxxxxxx>, John C Klensin writes : > > > The authenticity and integrity go hand in hand. The party > > looking up a domain name wants to know if the answer is > > correct. "Correct" in this context means that it was > > provided by the party that is authorized to provide it, i.e. > > the domain owner, and that the information hasn't been > > modified along the path to the user. That's integrity and > > authenticity combined. > > Steve, while I clearly agree with the above, I was trying to get > at the point that there are other elements that people might > reasonably consider part of authenticity. One is whether the > apparent domain is what it appears to be. Another is whether > the apparent domain owner is who it appears or claims to be. > That, in turn, is closely connected to the question of whether > there is enough information available to even determine what > ownership assertion is being made, i.e., whether the > user-accessible part of the registry database contains > information about the domain owner or merely some proxy or > "hidden registration" information that points to an entity that > conceals identities for hundreds or thousands of such domains. DANE isn't trying to be more than "DV". DNSSEC doesn't try to do more than "the answer matches what was entered in the zone for both positive and negative result". Both of those are actually very powerful. They don't however protect against someone registering microsoft.example.com and publishing a CERT for that name. For SMTP DV and assurance that the MX records or lack there of are not tamperered with is exactly what you want. You really don't care who the hoster is, just that you are talking to the authorised hoster. A similar thing for SUBMISSION. You really don't care about who is hosting the server for a domain as long as you can securely go from the domain to the submission server. For email you can get that user@domain sent the message. You don't get the linkage that "This Person" sent the message. Now for HTTP there are times when you care about whether a EV certificate is presented or not. At other times you only care that it matches the domain you are connecting to or not. > From those perspectives, a registrar or registry who might > collude with a criminal registrant to create deliberately > deceptive names and associated registration data (or whose > procedures allow similar results without explicit collusion) is > fully as much part of the threat model as a CA that issues > certificates without any attempt to verify the identity of the > entity being certified or who colludes in deliberately hiding or > distorting the information. > > Now "we" all know that has nothing to do with DNSSEC. It > provides assurance that what is in an authoritative zone and > what reaches the systems closest to the user that actually > validates the signatures and records are the same. But I'm > concerned that it gets oversold to the point that users and > others in the name-using environment hear what we say about "DNS > Security" as "if DNSSEC validates the record, then one has > assurances of the accuracy and integrity of the registrant and > registrant- DNS entry relationship" with "accuracy" and > "integrity" used in their street sense, not the much more narrow > and technical DNS and DNSSEC ones. > > Where that loops back to things like DANE is that DANE, at least > apparently, is making assertions about the identity of an > individual or other entity, not [merely] about validation of the > relationship of DNS records as installed/created in comparison > to those received. As with DNSSEC itself, that isn't a problem > if DANE is used carefully and with an understanding of what > assertions are being made and can be trusted. It could be a > significant problem if people over-promise (or over-believe) and > the use of DANE for critical functions becomes widespread enough > to become a tempting target for attacks of technical and/or > social or economic character (just as we have seen on CAs). DANE is only promising "DV" level certs. It can however disprove a invalid "EV" cert. If a "EV" cert is referenced in a TLSA record the difference between DV and EV comes from the CA not DNSSEC. > There is one sense in which trust models based on DNSSEC that > seem to imply certification of non-DNS entities (like > registrants) are more dangerous than ones based on CA chains. > In the latter case, there are good, and obvious, analogies to > many people's everyday experience. If one finds someone who > claims to be a notary but who operates out of the back of a > taxicab, exhibits no credentials or authorization, who is > willing to certify a document with no more identification of the > signer than the ability to pay a few dollars in cash, and > trusts him to certify signatures on an important document, it is > pretty generally understood what that certification is worth. > We aren't quite there with CAs, but most people are able to at > least understand applicability of the analogy. On the other > hand, when we build a system on top of the DNS and DNSSEC, > relying on elaborate rituals like the signing of the root and > layers of processes that are, for the typical user of the > Internet, indistinguishable from magic, and fail to be clear > that, e.g., no actual certification of registrant identity or > integrity is involved, people may trust the magic rather than > trusting DNSSEC as it is. DNSSEC and DANE certify that the domain name holder added the linkage from the domain -> cert. CA's try to go from the CERT -> domain but they are not part of the delegation process for domains so one can never be sure. Basically CERT's have been oversold for decades. > That, in turn, could lead to some really nasty surprises --and > loss of confidence in us and the institutions we ask people to > trust-- when the bad effects of that misunderstanding manifest > themselves in a damaging and public attack. > > best, > john > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx