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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf