]> Citrix

United States of America danwing@gmail.com

next generation unicorn sparkling distributed ledger This specification eliminates security warnings when connecting to local domains using TLS. Servers use a unique, long hostname which encodes their public key that the client validates against the public key presented in the TLS handshake. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the SETTLE mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Browsers are progressively requiring secure origins for new capabilities and features (). As secure origins are only obtainable, today, with a certificate signed by a Certification Authority trusted by the client, this leaves out devices and networks which cannot easily obtain such certificates. Such inability is due to network topology (e.g., firewall), lack of domain ownership, or complicated procedures. This draft discusses how a client can authenticate to HTTPS servers belonging to the local domain where the server name is a hash of the server's public key. By doing so, a secure origin can be established. This avoids the need for a certificate signed by a Certification Authority (CA) trusted by the client. This is a relaxed way of "doing HTTPS" for servers on the local domain.

Unique Host Names Web browsers and other application clients store per-host state using the host name, including cached form data such as passwords, integrated and 3rd party password managers, cookies, and other data. When a name collision occurs (e.g., the same printer.local name on two different networks) the client cannot recognize a different host is being encountered. By creating a unique name, existing client software (browsers, password managers, client libraries) can continue storing origin-specific data for each of unique name. A unique name is created by embedding the hash of the public key into the name itself. This achieves uniqueness and the encoding is also identifiable by the client to assist its validation of the server's public key (). Details on encoding the domain name are in .

Short Host Names Unique host names containing encoded public keys are awkward for users. This section describes how short names can also be advertised by servers and securely validated by clients, so that the short name is presented to users while the unique name is used for the TLS connection. A server already advertising its long name using can also advertise its short name. The client needs to validate they are the same server, prior to allowing the user to interact with the short name. The client can do this validation by making two connections: one connection to the long name and another to the short name and verify they both return the same public key and that both TLS handshakes finish successfully (proving the server has possession of the associated private key). Advertising both names enables incremental deployment within a local domain at the expense of user confusion (two names per device, like a human named both "Bob" and "Richard") and on-the-wire inefficiency.

• NOTE: Also to be considered is including both the unique and short host name in the SubjectAltName field of the server's certificate. This avoids an additional advertisement but has worse incremental deployment characteristics -- legacy software won't notice the other name in the SubjectAltName.

The client need only look for matching short name and unique name within the same TLD domain name (that is, if a unique name is advertised with a ".local" domain, the client does not need to look for its accompanying short name within ".internal"). To avoid the problems described in , the TLS data connection always uses the long name. Thus, after the client has validated the short name as described above and a user attempts to connect to the short name (by typing or by some other user interaction), the client instead makes a connection to the unique name. This reduces the integration changes within the client, as clients already separate server-specific data based on the server's hostname (e.g., Cookie Store API, Credential Management API, Web Bluetooth, Storage API, Push API, Notifications API, WebTransport API).

Operation

Client Operation When clients connect to such a local domain name or IP address () using TLS they examine if the domain name starts with a registered hash identifier in the second label and if the rest of that label consists of an appropriate-length encoded hash. If those conditions apply, the client performs certificate validation as described below. Upon receipt of the server's certificate, the client validates validates the certificate (, , and if using HTTPS). When performing such a connection to a local domain, the client might avoid warning about a self-signed certificate because the Certification Authority (CA) signature will certainly not be signed by a trusted CA. Rather, a more subtle indication might be warranted for TLS connections to a local domain, perhaps only the first time or perhaps each time. The client parses the returned certificate and extracts the public key and compares its hash with the hash contained in the hostname. If they match, the TLS session continues. If they do not match, the client might warn the user about the certificate (as is common today) or simply abort the TLS connection. Authorizing which servers are allowed on the local network is discussed in .

Server Operation A server running on a local network (see ) uses a unique host name that includes a hash of its public key. This unique name is encoded as described in . Existing servers might be configurable with such a hostname, without software changes. Oftentimes, servers operating on a local network already advertise their presence using and should continue doing so, advertising their unique name that includes their public key hash and optionally also a shorter nickname ().

Unique Host Name Encoding Details The general format is hostname, a period, a digit indicating the hash algorithm, and then the hash of the server's public key as shown in . The binary hash output is base32 encoded () without trailing "=" padding. Currently only SHA256 hash is defined with the value "0" (). While base32 encoding is specified as uppercase, implementations should treat uppercase, lowercase, and mixed case the same. (Base32 encoding was chosen instead of base64 or base64url encoding to avoid their illegal hostname characters and their case preservation requirement.)

ABNF of hostname encoding

An example encoding is shown in .

Identifying Servers as Local This section defines the domain names and IP addresses considered "local".

Local Domain Names The following domain name suffixes are considered "local":

• ".local" (from )
• ".home-arpa" (from )
• ".internal" (from )
• both ".localhost" and "localhost" (Section 6.3 of )

Local IP Addresses Additionally, if any host resolves to a local IP address and connection is made to that address, those are also considered "local":

• 10/8, 172.16/12, and 192.168/16 (from )
• 169.254/16 and fe80::/10 (from and )
• fc00::/7 (from )
• 127/8 and ::1/128 (from and )

Security Considerations

Validating Hostname Authenticity By associating a server’s public key with its origin (defined as the scheme, hostname, and port per ), a client can perform a TLS handshake with the server to ensure the server possesses the private key associated with that key hash. This allows the client to validate the authenticity of a hostname advertised on the local network (such as advertised via mDNS).

Authorizing Servers on Local Domain A client may also want to defend against rogue servers installed on the local domain. This requires legitimate servers be enrolled with a trust anchor system such as a local domain Certification Authority (e.g., ) or other system (e.g., ) and that enrollment verified by the client.

Public Key Hash Because the server's public key is encoded into its hostname, changing the public key would also change its hostname -- thus, its identity as known by the client changes, disrupting configuration of that server on the client (e.g., printer configuration, SMB share configuration, password manager). As such, an identity change is extremely disruptive, it needs to be avoided. This means the public/private key pair on a server needs to stay static. The tradeoff is a stolen private key allows an attacker to intercept traffic to that server for a long time, without requiring the attacker to retain access to the server (to steal its changed private key). This is not ideal but superior to plain text communication or conditioning users to accept self-signed certificate warnings for servers on the local domain.

IANA Considerations New registry for hash type, 0=SHA256. Extensions via IETF Action.

References Normative References This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Informative References W3C This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD. Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.home.arpa.' and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks. The Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'. Internet Assigned Numbers Authority Internet Corporation for Assigned Names and Numbers Google This document describes the "internal" top-level domain for use in private applications. This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names. This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link. IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface. [STANDARDS-TRACK] This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK] This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK] Lakeside Robotics Corporation This document extends the Automatic Certificate Management Environment (ACME) to provision X.509 certificates for local Internet of Things (IoT) devices that are accepted by existing web browsers and other software running on End User client devices. This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.

Example Encoding Server with private key in PEM format is: and public key in PEM format is: Using the binary format (DER) and hashed using SHA256 gives this hex value: Converting that hex value to binary and base32 encoded (without trailing "=") gives: After the hash algorithm identification digit (0 for SHA512/256) is prefixed to that base64url, resulting in: Finally, if this is a printer named "printer" advertised using ".local", the full FQDN for its unique name would be: and the full FQDN for its short name would be "printer.local".

Acknowledgments This draft was inspired by a document published by Martin Thomson in 2007; however, this draft takes a different approach by using unique names over the wire. Other systems have also utilized public key hashes in an identifier including Tor and Freenet's Content Hash Key. Thanks to Sridharan Rajagopalan for reviews and feedback.