| Network Working Group | P. Hallam-Baker |
| Internet-Draft | Comodo Group Inc. |
| Expires: April 26, 2015 | October 23, 2014 |
An Internet Presentation Level
draft-hallambaker-presentation-00
Paper submitted to the IAB Middlebox workshop describing an Internet architectural model.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 26, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
IETF process traditionally favors incremental change over radical change. But this approach fails when the problem to be solved is itself caused by divergent incremental change. Every one of the problems described in this document has been solved and not once but multiple times. And it is the proliferation and inconsistency of those solutions that is now the problem.
This first section of this paper surveys the key problems arising from the current Internet discovery architecture and the constraints within which any proposed solution must work. It is the view of the author that the proliferation of middleboxes is a symptom rather than the cause of these problems. Middleboxes do however represent a constraint which any solution must work within.
The second section argues that the areas in which the original Internet architecture now falls short do not properly belong exclusively to either the transport layer or the application layer. The need for middle boxes arises because the Internet model lacks a level of abstraction between the transport and application layers. The term 'Presentation Level' is used as a term for this new interface as the term 'Presentation Layer' is firmly established as the term of art for what lies between OSI layers 5 and 7.
While the idea that the DNS represents an Internet presentation layer has been advanced on previous occasions, this paper takes the concept further using the term presentation level to include host and service discovery, account presence protocols, Kerberos like key services and PKI.
The final section describes a realization the architecture described in the previous section through a compact set of simple Web Services that are individually of limited scope. Each of these proposals has been tested in an open source implementation and has been described previously a separate draft. These are:
Each of the first three proposals has its own independent value proposition that makes it a candidate for deployment even if neither of the other two ever advances. The last provides common infrastructure that supports the first three.
While the IAB call for papers suggests that the need for change arises from the deployment of middleboxes in the otherwise perfect Internet architecture, it is the opinion of the author that middleboxes are just one of the symptoms of the failure of the Internet architecture to keep pace with Internet growth.
The fact that the Internet architecture has survived with little major modification in the quarter century since deployment of DNS is testament to both the foresight of the original architects and the immense difficulty of making changes to an infrastructure on which over two billion people and the majority of global commerce depend. Denying outright the possibility that the Internet architecture model devised in the 1980s might fall short of current needs is the mindset that ossified the telephone network. The Internet was developed by people who had the skill and the vision to question the status quo.
At the time the foundation of the Internet was laid, computers were expensive and typically singular. The conception of the Inter-network as a network of networks was radical at a time when computer networking at most University campuses referred to the means by which dumb terminals connected to the central mainframe.
The modern Internet is a very different place. [RFC0801] describing the plan for the 'flag day' transition to TCP gives the number of NTP hosts in January 1982 as 200. This is roughly the number of networked devices I currently have in my house. And while my present residential computing configuration is an outlier today, such configurations will become typical in only a few years time.
The modern Internet connects between two and twenty billion hosts, the difference reflecting the difficulty of agreeing a definition of a host as much as uncertainty in the count. What is a host? A CPU? A CPU core? A virtual machine running on a CPU? But regardless of whether the Internet has grown by seven or eight orders of magnitude, the notion that every aspect the original architecture should be maintained unchanged is ideology, not respect.
Further, current estimates suggest that the global population will ultimately peak at between 8 and 10 billion. Extrapolating from current trends we should expect that every household item that currently uses electricity will eventually connect to the network. We should therefore adopt as a planning estimate that the Internet will eventually expand to at least ten trillion connected devices.
One architectural consequence of the growth of the Internet is that the Internet is no longer a network of hosts, it is a network of services. The so-called cloud is after all merely a name we give to the place Internet services reside because we no longer consider their physical location to be important. The core principle that underpins the cloud is that it is whether a function can be trusted that is important, not where it takes place. So why get excited over whether functions happen in a middle box or an end point if place does not matter?
Another significant architectural consequence is that the Internet is no longer a network of networks. It is a network of networks of networks and it is possible there are further levels of recursion. Middlebox appliances owe their existence in part to the fact that the interests of the user are not always the same as the interests of the local area network manager and their interests may in turn diverge from those of the Internet access provider whose interests are almost certainly divergent from their carrier.
Yet another difference resulting from scale is the need for security. When the Internet was a purely academic infrastructure and the users were members of academic institutions, there were few assets worth attacking and abuse was effectively controlled by an accountability model. As a result, the Internet culture many of us grew up with is profoundly maladapted to life in an Internet of 2 billion users. Even if only 1% of them were malicious (the usual expectation for a population is 10%) that would be 20 million malicious actors.
In particular we need to recognize that while everyone has the right to connect to the Internet, there is not a general right to connect to my part of it. In particular:
The received Internet security model is profoundly maladapted through the insistence of a single failure security model. This leads to the two arguments that are invariably made against any proposal for a new security control, that the new control is 'unnecessary' because another existing control is sufficient or that it will be ineffective because it does not cover every conceivable corner case.
An architecture that allows a breach to occur as a result of the failure of a single system is a bad architecture. Thus arguments of the form 'we don't need firewalls because systems should not be vulnerable to malware' are profoundly wrong because they assert that if the breach could have been prevented by control X then it is somehow bad architecture to insist on also deploying control Y. The correct security approach is to deploy both controls X and Y and a further infrastructure Z to provide feedback by reporting on breaches that should have been caught by one control but were not.
The biggest and most concerning consequence of Internet growth is the difficulty of changing the Internet infrastructures. IPv6, IPSEC and DNSSEC were all proposed over two decades ago. All were intended to become ubiquitous within a few years, no more than five at most. None has succeeded in becoming ubiquitous, not is there any reason to expect this to change until the reasons for the lack of deployment are addressed.
The term middlebox is a generic term for any network infrastructure that breaks the pure end-to-end IP architecture. As such they have been generally regarded as the result of ignorance or malice rather than a response to real world requirements. Only rarely has the question been asked if the end-to-end principle might not be universal in scope.
As previously mentioned, I have 200 network enabled devices in my residence. Ideally these devices would all be IP enabled devices but many of them are currently not IP enabled precisely because while it makes perfect sense to have a light switch to communicate using IP protocol it does not make sense for a lightswitch to be running an email server.
The principle of least privilege should be given at least equal respect as the end-to-end principle. And the least privilege principle states that my light switch does not need to be able to send email. Nor does my light switch need to be able to perform any form of communication that is not essential to its purpose.
Set out in these terms, the role and justification for Internet firewalls becomes obvious. As does the fact that firewalls are woefully inadequate for their intended purpose. While my firewalls could in theory prevent an attacker outside my network mounting an attack on my toaster oven, if the toaster oven is compromised, they cannot stop it conspiring with the refrigerator. And that is a serious concern.
The real problem with firewalls is not that they do not have a useful purpose but that they are unable to fulfill the purposes they are designed for. The main consequence of Internet firewall port blocking is that all new Internet services are layered on port 80 and port 443 rather than protocol specific ports, precisely to avoid 'problems caused by' middleboxes.
A realistic Internet architecture should respect the fact that the Internet is a network of networks and a network has a natural and legitimate interest in patrolling its border. The network perimeter is after all the point where responsibility for packets being emitted passes from one party to another. For the same reason, perimeter security will always have an important place in any serious security architecture. But that does not mean it should be the only place where filtering should occur.
In a default deny network, no network communication should take place that is not expressly permitted by network security policy. The network communications that are permitted for a light switch would not normally be as broad as those permitted to a desktop computer.
The idea that the local network is separate from the larger Internet is not new. It is in fact the origin of the Inter-Network itself. My private machines and my private network are my private domain. While the impact of cloud computing means that the precise physical boundaries are no longer clear, the Domain Name System provides the infrastructure that denotes the logical boundaries between domains.
Changing an infrastructure with ten billion moving parts is inevitably difficult and slow. But one aspect that makes the Internet particularly difficult to change is the rigidity of the Internet application interface.
When the Internet was first developed it was only one of many networking standards and so there was no 'Internet' API, there was a network API which supported the Internet as one option. A client application using one of the standard network stacks of the day, would connect to an Internet host by means of gethostbyname() system call to obtain the network address(es) of the host to connect to and then perform whatever platform specific call is required to establish a socket (or mailbox) to connect to the specified address.
A quarter century later, the application interface is essentially unchanged. The only difference being that on some object oriented platforms a socket is now known as a 'stream'. Meanwhile a large number of changes have taken place in the Internet infrastructure and the way it is used:
One of the problems that has prevented progress in this area is that the Application programmers desire for a new API that allows them the advantages of the modern Internet is frequently mistaken for a desire for an API that exposes more of the underlying complexity of the Internet and DNS.
What many of these defects have in common is that the Internet lacks a standard architecture for discovery and negotiation of Internet connections. While this problem has been solved on many occasions in many different ways there is no single coherent solution to the connection discovery problem.
The mechanism used for host discovery was not a choice for application protocol designers in the days of RFC802. The mechanism used for establishment of peer to peer or service connections should not be a choice for application protocol designers today. The IETF should have one mechanism that is consistently implemented and applied. And this mechanism should provide for all the needs of the modern Internet and anticipate future needs:
It is a truth universally acknowledged that gethostbyname is not a suitable application layer interface to the DNS. But the truth that is rather too frequently ignored is that application programmers really don't want to have to deal with anything more complex. While new APIs that expose the internals of DNS and PKI and directory infrastructures are highly desirable in their own right, these are not and should not be considered tools for use by the application protocol designer or implementer.
Application protocol designers are very fond of explaining that the discovery process is not a one-size-fits-all proposition, that there are subtleties and complications that mean that it is not possible for one particular discovery approach to meet every need. And these reasons are sound and correct and are also the reason why such decisions should not be taken by the application protocol designer at all. Such considerations are properly the concern of the network administrators and user and should be presented in a fashion that puts those parties in direct control.
Another common source of deficiency are the limitations of the DNS protocol and the DNS infrastructure. While the two are frequently considered to be equivalent they are in fact very different. It being far easier to change the former than the latter. Adding a Resource Record type to DNS requires no more than publication of an RFC. Changing the DNS infrastructure is much more challenging.
The DNS was originally designed as a mechanism to replace the hosts.txt file mapping Internet host names to addresses and early use was largely limited to this requirement. By the time more advanced uses came to be considered the vast majority of the deployed DNS infrastructure imposed a 500 byte message limit on DNS messages and each request packet could only specify one domain and one record type at a time.
Although the DNS protocol has been updated to remove the 500 byte limit and every major DNS server implementation updated a decade or more ago, many deployed residential network gateway boxes truncate messages to conform to the long obsolete requirement. Another rather more insidious limitation is that some middle boxes and platforms impose tight limits on the number of outstanding DNS requests that have not received responses.
While residential customers of an ISP can usually (but by no means always) overcome such limitations by providing their own network gateway box, this is by no means the only middle box attack performed on DNS. Whoever controls the DNS controls the Internet, a fact not lost on most ISPs.
It is now routine for DNS resolution services provided by ISPs to return a redirect to a Web site with an advertising page rather than the NXDOMAIN response code that should be returned when a domain name is not found. Some ISPs hijack NXDOMAIN responses from third party open resolvers to ensure that customers cannot avoid their unwanted intrusions.
DNS is a trusted infrastructure but the mechanism by which clients discover DNS resolvers is inherently untrustworthy. Internet clients depend on the DNS resolver returning trustworthy information. It is utterly ludicrous and unacceptable that the default DNS service be chosen by network proximity without regard for trustworthiness.
DNSSEC can alert the user to the fact that perfidy has occurred but does not provide a means of obtaining the correct, unadulterated result. While government agencies in most liberal democracies are anxious to conceal the fact that they are censoring and/or intercepting network traffic, this constraint does not apply to authoritarian regimes where the purpose of these practices is to deter rather than prevent expression of dissent. And there is no reason to believe that ISPs that have already decided that replacing NXDOMAIN responses from external DNS services that compromise their commercial interests will not attempt to strip out DNSSEC data if they choose.
The DNS is the discovery infrastructure of the Internet and the authoritative infrastructure that maps Internet domain names to assertions about those names. It is not however the only infrastructure that applications make use of during service discovery and connection establishment. Nor should it be.
Modern email infrastructures make extensive use of various types of blocklist. Although these blocklists are frequently distributed using DNS protocol they are by no means authoritative DNS responses. On the contrary, the value of these assertions lies in the very fact that they are provided by a third party and not the holder of the IP address.
Email was the first Internet infrastructure to make use of account identifiers of the form <username>@<domain>. Such identifiers are now used in a wide range of peer to service and peer to peer applications including authentication, instant messaging, voice and video.
Despite the ubiquity of such applications, no consistent presence infrastructure has emerged. Depending on the application designer's whim, names may be resolved by means of a variety of presence services including LDAP, OpenID, SAML, WebFinger or XMPP and while the DNS infrastructure is sometimes used as the means of resolving the <domain> component of the account identifier, this rather obvious approach is by no means universal or even the most common.
On many occasions, researchers have attempted to employ the DNS infrastructure itself as a presence infrastructure. There are structural factors that make this approach unlikely to succeed. In most medium or larger enterprises the DNS infrastructure is managed by a network administration team which is quite separate from the system administrators and IT support staff who issue user accounts. At any rate the fact that despite repeated attempts over the course of three decades, such approaches have invariably remained 'research' suggests that the approach is not ideal.
The most important gap in the Internet discovery architecture is the lack of a coherent security policy infrastructure to tell applications which security enhancements are supported by an Internet service and what credentials will be supplied. The lack of such infrastructure is the reason that twenty years after the deployment of practical PKI, security remains the exception on the Internet rather than the norm.
This shortcoming has of course been recognized in recent work and proposals such as certificate pinning and 'strict security' provide valuable benefits. But the approach in such proposals is necessarily tactical rather than strategic, designed to provide the best security in the difficult circumstances of the legacy Internet rather than a principled architecture.
There has never been a shortage of proposals for ingenious mechanisms for extracting important and useful information from the DNS. The problem that has received far less attention is the problem of how to ensure the important, useful and accurate information can be inserted into the DNS in the first place and how to keep the inserted information up to date.
In the early Internet, DNS configuration was essentially static. Modern network configurations require a more dynamic approach. One of the more problematic consequences of middlebox proliferation is that they typically introduce a veto point into the network that must be configured to allow Internet services and peer to peer applications to receive inbound connections. This is also one of the main reasons that the deployers consider them to be attractive. Rather than attempting to prevent the network administrators from deploying devices that provide control through ad-hoc heuristics we should attempt to design a system that gives them the control they seek.
Deployment in the cloud and PKI based security both introduce a whole additional dimension of dynamic discovery and administration challenges. A node in a cloud computing surface might support an Internet service for only a few hours.
According to Wikipedia, the Internet Application layer includes BGP, DHCP and RIP. While these are certainly not transport layer protocols it is hard to argue that they sit any better in the application layer. If a new model for describing the Internet architecture were to be developed these would surely sit in a quite separate compartment to protocols such as Telnet SMTP, IMAP, POP, NNTP and FTP that support applications.
The OSI layered model is a poor abstraction for the Internet architecture because it describes what takes place in the layers rather than the interfaces between the layers.
It is the interfaces between the levels that are the essential part of the model. We can replace the data link layer with messages strapped to pigeons provided that the interface to the Network layer is maintained.
Every level in the model carries the same data content in different representations. It is the identifiers used between the levels that changes.
We note in passing but do not have the time to go into the topic in detail, that understanding the model in terms of interfaces rather than layers is also key to establishing the proper place for Virtual Private Networks (VPNs) and Software Defined Networking (SDN). A VPN is not a 'Layer', it is an object that sits above the Network level and presents the Network/Transport interface to both the Network and Transport Level. SDN performs the same role at the Data-Link/Network layer.
In the now defunct OSI model, the Presentation layer was an intermediary through which all communications between the Transport and Application layer passed being transformed in the process.
What is proposed instead is that the discovery, performance and security features that mediate between the Transport and Application layers reside in a compartment labelled 'Presentation Service' that does not necessarily fully extend between the two:
+------------------------------------------+
| Application Layer |
+------------------------------------------+
| | |
+--------------+ +--------------+ |
| Presentation | | Presentation | |
| Services | | Layer | |
+--------------+ +--------------+ |
| | |
+------------------------------------------+
| Transport Layer |
+------------------------------------------+
DNS is a Presentation Service. Following the traditional approach, an application first discovers the IP address using the DNS and then establishes a direct connection. Once discovery is completed, the DNS plays no further role in mediating the connection. Kerberos and PKI are likewise Presentation Services and follow the same use pattern. In contrast, TLS is a Presentation Layer since all communications between the application and transport layers are transformed.
One important protocol that does not fit within this architectural model is HTTP and this is precisely because HTTP was originally conceived as an application protocol but is now commonly employed as a presentation layer. One visible consequence of this inconsistency is the conflict between the requirements of the Web browser and Web services communities in the design of HTTP/2.0.
Although HTTP/2 eliminates some of the inefficiency arising from the use of RFC822 style text headers in the HTTP/1.1 protocol design, it does not provide the features that one would expect or require from a fully featured multimedia delivery protocol with multiple content streams being delivered at individually negotiated Packet layer Quality of Service. Nor does the traditional Internet architecture suggest such an approach is even possible.
While the realization of such a presentation layer would likely require innovation at both the Presentation and Transport layers and is therefore outside the scope of this document, it should be the function of the Presentation l ayer to inform an application that such a capability was available and thus enable a graceful transition between the current protocol and the new. Thus a browser attempting to connect to http://example.com/ in a 2020 Internet might discover that the HTTP/1.1 and HTTP/2 protocols are supported over a TCP transport and that in addition HTTP/3 is supported over an as-yet-undefined 'Extended' ETCP transport.
The DNS infrastructure is regarded as holding a privileged position in the Internet architecture as it is the authoritative infrastructure for resolving DNS names. But what does the term 'authoritative' mean and is a result from an authoritative infrastructure necessarily better than a result that is not authoritative?
In considering the issue of naming we distinguish an authoritative infrastructure from a service protocol. What makes a naming infrastructure authoritative is that it serves as the 'ground truth' for a set of names. Thus when in the early 1990s a Sun workstation used the yellow pages protocol to resolve DNS names, the application clients did not use DNS protocol to resolve DNS names but they were still logically connected to the Internet since the DNS infrastructure provided the ground truth for the name resolution process.
The DNS infrastructure is, was and will always be the authoritative infrastructure for resolving Internet names. The DNS protocol is merely a protocol that supports access to the DNS infrastructure and can change if necessary to meet changing constraints and requirements.
While results from the DNS infrastructure are authoritative, they do not necessarily represent a an objective ground truth that is guaranteed to be the same regardless of who is asking the question and when the question is being asked. Only cryptography can provide ground truth in a communication infrastructure and then only with respect to a key and not to facts.
Consider the case in which a DNS registration is known to be used by organized crime. This situation has occurred on numerous occasions and is unavoidable in any system that is designed to provide no obstacles to legitimate registrations. there have even been cases in which DNS registrars have existed for the sole purpose of facilitating criminal activity. The mere fact that a DNS name is registered does not require a discovery service to resolve it.
There is a clear need for a curated discovery service just as enabling such a service presents a clear threat of abuse. Curated discovery introduces a new control point and some see a slippery slope that begins with filtering out criminal activity expands to block access to pornography and eventually ends up as government censorship of political speech.
But slippery slope or not, relying on unfiltered authoritative services replaces the possibility of abuse with certainty of attack. The real question should be not whether curated discovery is possible but who is in control. An infrastructure that puts the end user in direct control of the choice of discovery service can be used as a mechanism to evade government censorship rather than enforce it.
The DNS infrastructure provides us with an authoritative answers to questions about DNS names but not necessarily answers to the questions that a particular application needs.
An A record binding the name ipv4.example.com to the address 10.1.2.3 does not answer the question a network host that can only speak IPv6 needs to ask.
In the traditional approach to IPv6 transition we introduce some form of middlebox performing v4-v6 address translation, some form of discovery mechanism by which the network host can discover the translation middlebox and some form of addressing convention allowing the host to direct an IPv6 packet to an IPv4 endpoint. While this gets the job done, it requires the IPv6 network host to continue to support IPv4 for as long as there are any IPv4 hosts remaining in the network which for practical purposes means forever.
In a simpler approach the network host implements a pure IPv6 stack with no support for legacy IPv4 or any transition mechanism. When the host attempts to connect to an Internet service that is only available in the IPv4 network, it would rely on its DNS resolver to return a non-authoritative AAAA record giving the IPv6 address of a translation service.
The second approach makes the DNS resolver the mediator of the IPv4-to-v6 transition process. If a legacy IPv4 network sets up a local translation gateway, a single change to the resolver configuration allows every host using that resolver to take advantage of it. Centralizing the configuration provides the necessary agility.
As we have seen, the authoritative response is not necessarily the one that answers the right question. Where does this leave DNSSEC which is designed to allow verification of signatures on authoritative responses?
While some DNSSEC supporters will no doubt argue that allowing a client to act on non-authoritative DNS information opens up a Pandora's box of horrors, the true situation is far less worrisome. Using DNSSEC to sign A and AAAA records is like using an armored delivery truck for delivering packages to a person living on a park bench. An IP address is a means and only sometimes an end-point in an Internet conversation. Resolver modification of A and AAAA should not therefore be cause for panic. But what should?
The Presentation service model offers a useful framework for resolving this question. The interfaces between layers are characterized by a particular type of identifier. The IP address and protocol type characterize the interface between the Internet and Transport layer. The IP address and port number characterize the interface between the Transport layer and the presentation layer. The interface between the presentation layer and the Application layer is characterized by DNS names and cryptographic credentials.
It is appropriate therefore to perform end-to-end validation of signatures on records that bind cryptographic credentials to a DNS name and to limit other DNSSEC validation to the DNS resolution service.
Discovery is the process of resolving names to services and names to accounts. In order to establish a solid basis for a Discovery architecture we must first establish a consistent approach to naming.
While Uniform Resource Identifiers are commonly considered to be an 'Internet' naming architecture, the scope of URIs is universal and not limited to the Internet. URIs therefore represent a naming infrastructure layer above the Internet rather than a part of the Internet itself.
In practice the Internet has three naming/addressing infrastructures that are established with clarity:
Of these naming conventions, only the last two are visible to Internet endpoints in normal circumstances. At a pragmatic level, an IP address is defined as where packets sent to that address will go and a DNS label is defined by the responses returned by the DNS infrastructures.
The interpretation of Internet account identifiers is not established with similar clarity. While SMTP and XMPP both adopt a reasonable and consistent approach to interpretation of RFC822 account names, the lack of a coherent discovery architecture has led to what is at best an unhelpful divergence of approaches and at worst a demonstration of the fact that a hundred intelligent and accomplished Internet protocol developers and a dozen major companies can commit resources to the notion that users will understand a URI is their account name.
Internet account names are account names of the form introduced in RFC822, i.e. <username>@<domain>.
The authoritative source for resolution of an Internet account name is an Internet service that is advertised in the DNS by the holder of the corresponding <domain>.
At present there are application protocols, notably SMTP a nd XMPP that follow this model but the authoritative resolution of the account is limited to the application. There is no authoritative Internet service resolving Internet accounts in the general case.
The problem here is not the lack of a protocol. It would be easy enough to specify a subset of the OpenID protocol that excluded URIs, XRIs and other identifiers that are not Internet accounts. The problem is that the service has to be recognized as authoritative. And this cannot happen when OpenID is still architected as a vehicle for establishing a new Internet naming infrastructure for accounts with all the commercial advantages that would imply for the parties who control the institutions controlling the alleged IPR.
From a practical point of view, the authoritative infrastructure for Internet accounts is email. Established practice is that when a user forgets their account identifier or password they are asked to respond to a message sent to their Internet account address using the SMTP protocol. While this approach is expedient, the user experience is awful and so Web site designers avoid consulting the authoritative service wherever possible. The user experience and the security of this infrastructure could be greatly improved if a protocol was designed to meet this specific purpose.
The Personal Privacy Environment introduced the concept of Strong Email Addresses. A strong email address is of the form <fingerprint>?<username>@<domain> where the <username> and <domain> portions have the usual meaning and <fingerprint> is a cryptographic digest identifying a public key which represents the root of trust for establishing communication with the specified Internet account.
In the simplest form of strong email address <fingerprint> is a PGP public key fingerprint associated with the address. In a more general approach, <fingerprint> is the fingerprint of a public key that is a root of trust for a PKI. This may be a formal PKI hierarchy established by a CA, a lightweight personal hierarchy or a Web of Trust.
In this paper we extend this approach to DNS labels to establish ground truth for DNS names. Following the convention established by punycode domain names, a strong domain name label has the form "xx--" + <fingerprint> where <fingerprint> is a cryptographic digest identifying a public key which represents the root of trust for authenticating the domain name.
Thus if we wish to describe a domain 'example.com' to be interpreted with respect to the ICANN DNSSEC root of trust we would write:
example.com.xx--49AAC1-1D7B6-F6446-702E5-4A1607-3716
49AAC11.. being the fingerprint of the ICANN DNSSEC root.
Representing the ICANN DNSSEC root in this way is not particularly interesting as it is the implicit root of trust for all DNSSEC names (although it could be very useful in the case of a root roll over). The strong name representation becomes much more interesting when a third party trust provider is involved such as a CA:
example.com.xx--cd9b97-e67b74-99a33f-59128e-f2cd46-3156e5-f6bd
The advantage of using a strong email address is that it provides a layer of abstraction that conceals the complexity of the trust infrastructure that lies beneath it in the same way that IP addresses provide a layer of abstraction above the routing infrastructure and URIs provide a layer above the application protocol stack. This has a profound impact on how we address the problem.
In the traditional approach to Internet PKI (including SAML and DNSSEC) the approach we follow is to obtain signed assertions relevant to the proposition at issue from trusted sources, verify the provenance of the assertions received by attempting to validate the signatures and decide if the assertions are valid. In this model an assertion is either valid or invalid. So when a party is acting as an intermediary on behalf of another they are forced to respond as if their answer is based on ground truth when it almost certainly is not.
Simple Distributed Security Infrastructure (SDSI) by Rivest and Lampson attempted to resolve this dilemma by introducing a key centric PKI in which the namespace is intrinsically relative. Thus in SDSI we talk about 'Bob's Alice' rather than 'Bob'. Ground truth is introduced into the SDSI scheme by giving a small circle of privileged parties reserved names (the paper suggests verisign!!, dns!!, usps!!). This approach left SDSI deferring rather than resolving the ground truth problem.
Using a fingerprint of a public key provides a ground truth that is objective and unambiguous. We now have a vocabulary in which Web Service A can describe to B the trust assertion it has received that is grounded by trust provider C. And that allows us to be explicit as to whether a B is relying on A or C as the trust provider.
The traditional IETF approach to the discovery and maintenance problems has been piecemeal. Instead of calling gethostbyname and opening up a socket, the application programmer is expected to interact with the half dozen components of a disparate discovery and network configuration infrastructure, hoping that the network administrators at the service to which connection is to be established has done their part correctly. While these piecemeal approaches generally anticipate a gradual migration of the relevant functions to the DNS, the only process by which the DNS infrastructure is expected to improve is through the gradual attrition of non-conformant systems.
In this paper we take a different approach. Rather than burden the application programmer with new chores, we reduce the effort expected of them by providing a new Presentation API that provides an abstraction layer above all the Presentation services that might be used to establish a connection.
To establish a connection to an Internet service, the application programmer need specify only the domain name of the service to connect to and the service protocol identifier. The implementation library then returns either a stream (or socket) connection to the requested service with the best available security and performance characteristics as specified by the service security policy or an error report explaining why a connection was not established.
For example, if a Web browser were to attempt to resolve the URL http://example.com/ the browser client would call the discovery API specifying "example.com" as the domain name and "_http._tcp" as the service protocol identifier. The implementation library finds the service is supported by five points of presence and determines that the example.com service security policy is to always offer TLS. A TLS connection is established to an appropriately selected point of presence consistent with the security credentials specified in the security policy and delivered to the application programmer.
Offloading the work of establishing the Internet connection from the application programmer to the implementation library offers agility as well as simplicity. If a new high performance transport layer protocol were devised that replaced TCP, every application using the high level discovery API running on a platform that supported the new transport layer protocol can make use of it immediately with no application update required.
The same API would support peer to peer connections in the same fashion but specifying the account identifiers of the parties attempting to connect in place of the domain name.
The only precondition for implementing a consistent discovery API is that the rules of discovery be clearly and precisely specified. The discovery process might be uniform across all application protocols or allow for variations to support legacy approaches. For example the use of MX records rather than SRV records for SMTP service discovery. It is not even necessary that all the required information be provided through the DNS provided that the rules for using information from other sources are precisely specified.
While this paper proposes a major change to the Internet architecture, the implementation of this change is surprisingly simple. This is because the principal change proposed is to recognize approaches that have been longstanding practice.
The implementation of the Presentation services follows a modular approach. Each service is implemented as a JSON/REST style Web service using either HTTPS or a lightweight UDP transport as the base.
SXS-Connect is a JSON-REST Web Service that is used to establish a connection to a Web Service. As with a DNS SRV record, a service connection is a logical connection that may comprise connections to multiple physical hosts. Unlike an SRV connection, the physical hosts may advertise services that differ in the protocol versions, features, transport, syntax etc.
Authentication of client and server is supported by means of public key or one time use credentials. Irregardless of whether the original connection to the SXS-Connect service was authenticated or not, communication between the client and the Web service is typically secured by means of a shared secret that is used to protect the confidentiality and integrity of every transaction message.
In normal operation a client discovers the SXS-Connect service through a 'bootstrap discovery' mechanism based on either DHCP or the DNS. Depending on the type of service provided, bootstrap discovery might be repeated on a frequent basis (e.g. each time the bootstrap DNS parameters expire), whenever the service signals a need for reconfiguration or never.
As shown earlier, one of the biggest obstacles to making effective use of the DNS as a comprehensive discovery infrastructure are the limitations of the legacy DNS client-resolver protocol. In particular the conflicting demands of lowest possible service latency from the application programmers and the limits of message size and queries per request imposed by the legacy middlebox infrastructure.
Attempting to sort out the mess on port 53 is pointless. Any proposal that inherits the legacy DNS UDP port will inevitably inherit the legacy DNS restrictions as well. But any solution that does not meet the severe performance criteria demanded of the Web browser providers, particularly with respect to latency is doomed, as is any proposal that does not guarantee compatibility with all legacy network environments.
Private-DNS is a replacement transport for the DNS client-resolver interface that offers two alternative transports, a new UDP based transport that is designed to provide optimum performance while being compatible with roughly 97% of legacy network configurations and a HTTP transport which is slow but provides the best practical guarantee of network compatibility. In either case, every message is encrypted and authenticated and responses securely bound to requests.
Unlike competing proposals based on DTLS, the Private-DNS transport is designed to support DNS conversations rather than single transactions. This permits lower latency and more comprehensive results.
When connecting to a Web site www.example.com, a Web browser today typically performs queries for A and AAAA records at www.example.com. In theory, the DNS protocol permits multiple queries per message, in practice this capability is not viable as a message can only return a single response and much of the infrastructure does not support it. The requirement that every query be performed in a separate query transaction discourages speculative requests for SRV, DANE or other DNS records that might contain useful information. This in turn discourages definition of useful record types.
As in the traditional DNS UDP transport, the UDP transport employed in Private-DNS requires that the request portion of a DNS conversation fit within a single UDP packet but up to 16 packets may be returned in a response.
The practical result of this change is that every reasonable DNS conversation can be realized in a single Private-DNS interaction without performance penalty. Instead of protocol designers and DNS administrators constantly having to worry that an overamitious design would lead to poor performance or protocol failure, it is quite unlikely that the limits of the transport would be reached inadvertently.
Private-DNS provides a low level interface to the DNS system allowing a network client to implement a Presentation service on the local machine. But the responses returned by Private-DNS are limited to those provided by the DNS and as previously noted, the authoritative answer is not always the one that is desired.
OmniQuery is a Web service that exposes the Presentation level discovery API as a Web Service.
A client asks 'How can X connect to Y to perform protocol Z' where X and Y may be Internet accounts or domain names and Z is the name of an Internet service. The server then returns all the information that the client might want to know to establish the best connection for that purpose. In addition to the IP address and port number, a server might specify the transport to be used (e.g. UDP, TCP, some new transport) the cryptographic enhancements to be applied (e.g. TLS), required credentials and any other information that might be needed.
Unlike the traditional DNS discovery infrastructure, OmniQuery allows both ends of the communication to be specified. The mechanism by which alice@example.com connects to example.com might be very different to the mechanism by which other parties connect. Connections may also be established between peers (e.g. alice@example.com connects to bob@example.com).
One consequence of this difference in approach is that rather than accepting service from the closest discovery service, as is typically the case with DNS, clients select a particular service for OmniQuery service which is used regardless of client location.
One of the principal weaknesses in the current DNS infrastructure is that while there is a well developed standards based infrastructure for extracting data from the DNS, there is no similar standards based infrastructure for entering information. Provisioning services for other directory infrastructures and PKI are equally unsatisfactory.
OmniPublish provides a high level interface that allows an Internet host to advertise an Internet Service and to obtain all the necessary cryptographic credentials to act in that role. In a typical deployment, an OmniPublish service is connected the DNS service, PKI and network firewall so that it can perform all the configuration steps necessary to configure the network to bring up the service.
For example, consider the case that an Internet host is to be configured to establish a mail service. In the normal approach, the network administrator would configure the server on the Internet host, configure the firewall to permit delivery of mail and finally configure the local DNS settings.
Not only is this approach complex, it is fragile. Any error in the network configuration is likely to result in an inoperable service. Network administrators are therefore understandably reluctant to make unnecessary changes. DNS records and firewall configuration settings that are not fully understood tend to be left untouched. This makes manually configured DNS a rather unreliable source of security policy records. While the records may be authoritative, they are frequently out of date. Mail abuse filters do not make mail delivery decisions on DKIM or SPF records without first applying heuristics designed to limit the impact of stale records.
Generating the network configuration automatically allows the OmniPublish service to ensure that it is both correct and up to date. If a major change in network configuration is to be performed, the OmniPublish service provides a single point of control through which the change can be administered.
Middleboxes have emerged to meet a set of requirements that cannot be achieved within the traditional Internet model. Middleboxes are neither the result of ignorance, nor a 'necessary evil'. It is time to accept that middleboxes serve functions in the Internet infrastructure that are equally important to those traditionally recognized.
Describing the Internet model in terms of interfaces rather than functions and adding a presentation level clarifies the functions of middleboxes and how those functions might be achieved in ways that do not compromise functionality in the ways that legacy middleboxes do.
A set of three JSON based Web services are proposed to properly encapsulate the interaction between the Presentation layer and the Applications and Transport layers. These are OmniPublish, OmniQuery and Private DNS, each of which is built on the service connection protocol SXS-Connect.
| [I-D.hallambaker-privatedns] | Hallam-Baker, P., "Private-DNS", Internet-Draft draft-hallambaker-privatedns-00, May 2014. |
| [I-D.hallambaker-wsconnect] | Hallam-Baker, P., "JSON Service Connect (JCX) Protocol", Internet-Draft draft-hallambaker-wsconnect-05, January 2014. |
| [I-D.hallambaker-omnibroker] | Hallam-Baker, P., "OmniBroker Protocol", Internet-Draft draft-hallambaker-omnibroker-07, January 2014. |
| [I-D.hallambaker-omnipublish] | Hallam-Baker, P., "OmniBroker Publication Protocol", Internet-Draft draft-hallambaker-omnipublish-00, May 2014. |
| [RFC0801] | Postel, J., "NCP/TCP transition plan", RFC 801, November 1981. |