Phillip Hallam-Baker wrote: > > What really worries me is that there are people who are busy inventing new > discovery mechanisms for Internet protocols via HTTP who are completely > ignoring the existing DNS infrastructure. Well, I'm worried about the security nightmare that is going to happen when two different technologies from the IETF that are based on mutually exclusive assumptions are combined into solutions for the marketplace. In the security area, the focus in recent years has been on making pervasive use of hostname-based server endpoint identification. However, this scheme is based on the flawed assumption that users provide these hostnames strictly in a trusted fashion. In the Web, however, most https-URLs that user access, originate from html-pages that were received insecurely through http and invisble to users, rather than being conciously typed by users or being bookmarked https urls. In the apps area I'm seeing proposals to provide and use service location discovery on a global scale. While it might be possible (one day) to perform the lookup itself in a secure fashion, e.g. through DNSSEC, the hard problem is that a desire to resolve an abstract service into arbitrary hostnames is mutually exclusive with the concept of "user provides trusted hostname" for hostname-based server endpoint identification. Personally, I think that a scheme of service location discovery has merit, even one that is untrusted and insecure. And I've been considering hostname-based authentication a fatally flawed idea from the day I got to know them in Kerberos in 1995. In theory, one could get entirely rid of hostnames in the authenticated identities of services with a trusted and secure directory service, that translates a user-provided trusted(!) abstract service name into a 3-tuple of ip-address, service-port and security identity (I think DCE could do this) ... but there is the problem that trust scales at best to a small number of closely related organizations, and never beyond. The current practice with TLS in WebBrowsers is definitely not about trust -- it is about _faith_. Faith in each and every of the ~40 Gods around the world that managed to get their "trust anchor certificates" preconfigured in the TLS-enabled products of you software supplier. To top it off, there appear to be Gods that disclaim liability for completely unverified stuff in the certificates they sign in something called a "Certificate Practice Statement" (CPS). So it is faith, because most consumers of the technology do not know and neither care who those Gods are and what they do or disclaim -- there is only the underlying hope and belief, that whoever it is and whatever they do, that it is well-intended. I guess it is inevitable that whenever humans try to expand trust beyond the boundaries of their monkeysphere, they will make compromises that effectively substitute an original model of trust with a concept of faith. > > As for the interaction with DNSSEC, I think it is double ended. At the > moment DNSSEC has no particular function. If we only implement what is > described to date there is nothing that DNSSEC can do that is not already > done better by the existing infrastructure of SSL and CA issued Domain > Validated X.509 certs. DNSSEC provides exactly what is described in the last sentence of the introduction of rfc-4033: The DNS security extensions provide origin authentication and integrity protection for DNS data, as well as a means of public key distribution. These extensions do not provide confidentiality. DNSSEC provides this from the start and in full. But there is never going to be anything else that DNSSEC will be able to provide. In particular, DNSSEC is never going to be able to provide "trust", not now, and not in the future. -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf