Re: There should be a design pattern, not patterns.

[Mark Andrews <[e-mail]>]

In message <CAMm+LwgK=[e-mail]>, 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: [phone]                 INTERNET: [e-mail]