In message <CAMm+LwgK=umaMNjvgNxsKv4k8+z8hRKfMD3oCpMfmFaL4RBe2A@xxxxxxxxxxxxxx>, Phillip Hallam-Baker writes: > The biggest weakness in the way that the IETF approaches problems is > that it is overly reductionist. Problems are separated out into 'DNS' > and 'PKI' parts, privacy is separated from integrity. Which would be > fine if the problem we face is that we can't do privacy or integrity > or whatever as we can. > > The problem we face with Internet protocols today is that security > falls through the cracks in the architecture. And that isn't a > surprise because those cracks are precisely the point where the > attacker is going to place a jackhammer and pound. > > > > If Internet architecture means anything then there should be one > canonical approach whereby a client discovers how to connect to a > service. This comprising discovery of: > > * The IP Address > * The Port > * The Transport protocol > * The Transport layer security parameters. > * The Application layer protocol > * The Application layer security parameters > > Obviously DNS should play a major role in this discovery scheme but > the mere fact that a claim is made authoritatively in the DNS does not > necessarily mean that the client should accept that assertion or > connect. > > There should however be one canonical discovery approach and it should > not be a protocol designer's choice. The decision to use RFC822 style > headers, XML or JSON is a legitimate design choice. How to do > discovery is not. There should be one way to do it. > > > This is why I was critical of DANE which was sold as a key discovery > protocol but became a security policy mechanism. Now we need a > security policy mechanism but DANE is not that mechanism. Because DANE > begins with the assumption that you are going to use TLS and that > should be something that the security policy tells you to do. > > DNS should be a one stop shop telling the client everything it needs > to connect. And one requirement for that is the ability to > authenticate the authoritative statements of the DNS name owner and > this in turn should be the driver for DNSSEC. > > As far as a typical domain name owner is concerned, the total cost of > ownership of DNSSEC is north of $3000 today. Thats the cost of either > training staff to do the deployment or finding someone capable of > doing to them. Expertise is expensive and most people who work in IETF > have no idea just what the gap is between their skills and the typical > Internet network admin. Walk through the 'sales' room of any CA and > you won't hear much sales going on. The talk is all 'and now open up > your apache.conf file...' So positioning DNSSEC as enabling a free > replacement for the cheapest WebPKI certificates ($50 or less) is > beyond clueless. Not only is the sales proposition a bad one. > > But much more importantly, it is actually selling DNSSEC short. > > DNSSEC should be the enabler for the next generation of Internet > security, the enabler for comprehensive security policy. If that is on > the table then it is a simple matter to roll out DNSSEC as an upsell > to every DV certificate holder. We have the customer support people > who can do the necessary hand holding to get someone's DNSSEC deployed > and security policy set correctly. And if we can do that in bulk we > can do it for cheap. > > > Unfortunately there are some problems with the basic DNS protocol that > make it less than ideal for that purpose. These are > > 1) One request and response per round trip. Although the DNS protocol > allows for multiple queries per request, the response only has one > slot for the status result which makes multiple requests per packet > almost unusable. No, the header allows for a count of more that 0 or 1 questions. The protocol does not because it does not have a way to specify multiple errors. There is only a single error code in the header. > 2) Requests are not authenticated in any fashion, not even the minimal > TCP authentication of returning an acknowledgement. And so the > protocol is open to abuses such as amplification attacks that are > exacerbated by DNSSEC. And there is working code that defeats such abuses and gives similar levels of authentication as TCP does. It is also incrementally deployable. > 3) Cruddy middlebox implementations that enforce obsolete constraints, > sabotaging attempts to overcome legacy constraints. > > 4) Lack of confidentiality protections. > > > Now we get to the part that I find incomprehensible. We all agree that > the DNS client-resolver protocol is a major obstacle in DNSSEC > deployment. So why on earth are we discussing proposals that ONLY > encryption to address the privacy issue when we can solve ALL FOUR > problems for the same cost? > > Back in the Louis Freeh days we made a big mistake in insisting that > all security be end-to-end or nothing at all. Guess what nothing at > all won. We were so obsessed with stopping Louis Freeh we were blind > to the fact that we had designed a system that most Internet users > could not and therefore would not use. We would be making a similar > mistake if we decide to make the DNS client-resolver protocol secure > against disclosure attacks but fail to address the other limitations > that make it generally unsuited as a general discovery protocol. > > > So what should we do instead? > > First we need to fix the DNS protocol with a two stage protocol that provides: > > 1) A lightweight key exchange with mandatory server authentication and > optional client authentication capabilities. [We can build this out of > TLS]. The result of this exchange being an opaque identifier (i.e. a > ticket) and a shared secret. > > 2) A stateless UDP query response mechanism that provides > authentication and confidentiality protections in which requests are a > single packet but responses can be multiple packets. While fitting > enough information into 500 bytes or 1280 bytes is very hard, two > packets is plenty for most cases and even the most complicated > discovery cases rarely require more than four. > > > Reforming the DNS protocol in this fashion is actually a lot simpler > than the competing proposals but it solves all the problems with the > DNS protocol, not just the cause du jour. > > The DNS client is going to connect to a DNS resolution service and > establish a service connection that potentially persists for a very > long time. If the device is an encumbered one it might be years. > > > It is now possible to make a complicated DNS discovery request for the > same latency cost as traditional A record look up: > > Traditional query: > example.com ? A > > Complex discovery > example.com ? A > example.com ? AAAA > _http._tcp.example.com ? SRV > _http._tcp.example.com ? POLICY > _80.example.com ? TLSA > > Even though we are making 5 queries instead of one, this easily fits > into one UDP request packet. And the resolver can easily return all > the answers and the full DNSSEC query chains in 4 to 5 packets without > trouble. > > > In about 3% of cases it is not possible to make UDP queries. This is > pretty much the same as the number of cases where port 53 DNS is > sabotaged. So a fallback strategy to a HTTP web service is required to > provide a connection guarantee. But while it is essential for a > discovery process to work in 100% of network situations we do not > require latency to be optimized in every circumstance. > > Now this is a protocol design pattern. It is completely general. It > leverages legacy SRV and TLSA records where they are present but we > can make use of new record types such as the POLICY record where the > design does not begin with the requirement to be backwards compatible. > > > The DNS resolver is always a trusted function. If you don't trust the > resolver then go to the authoritative servers directly. Embracing the > fact that the resolver is trusted means that we can leverage it to > provide us with additional services. We could even use it as a > kerberos ticket broker which isn't something most folk would go for > today but that approach will suddenly become inevitable should someone > ever come close to building a quantum computer. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx