A DNS Resource Record for TLS Server Name Indication (DNS SNI)
draft-schwartz-dns-sni-02

Document Type Active Internet-Draft (individual)
Last updated 2017-02-17
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        B. Schwartz
Internet-Draft                                                    Google
Intended status: Standards Track                       February 17, 2017
Expires: August 21, 2017

     A DNS Resource Record for TLS Server Name Indication (DNS SNI)
                       draft-schwartz-dns-sni-02

Abstract

   The SNI record type allows a domain owner to specify the "server
   name" to indicate in TLS connections, if it is different from the
   domain name.  This allows domains that use shared hosting and
   wildcard or multi-domain (UCC) certificates to change the only domain
   name shown in cleartext, to prevent a passive adversary from
   identifying exactly which domain a user is accessing.

Status of This Memo

   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 August 21, 2017.

Copyright Notice

   Copyright (c) 2017 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

Schwartz                 Expires August 21, 2017                [Page 1]
Internet-Draft                   DNSSNI                    February 2017

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Threat example: shared hosting service  . . . . . . . . .   3
   2.  Concept . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Need for a new record type  . . . . . . . . . . . . . . .   4
       2.1.1.  Using SRV . . . . . . . . . . . . . . . . . . . . . .   5
       2.1.2.  Using TLSA  . . . . . . . . . . . . . . . . . . . . .   5
       2.1.3.  Using TXT . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Client Requirements . . . . . . . . . . . . . . . . . . . . .   5
   4.  Server Requirements . . . . . . . . . . . . . . . . . . . . .   6
   5.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  Performance Considerations  . . . . . . . . . . . . . . . . .   7
   8.  Considerations for optimizing privacy . . . . . . . . . . . .   9
   9.  Extensibility . . . . . . . . . . . . . . . . . . . . . . . .  10
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     12.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Modern Internet standards are designed to avoid unnecessarily
   revealing sensitive information about a user's behavior to a passive
   adversary.  One key piece of sensitive information is the name of the
   domain that a user is visiting.  Most commonly, this is the DNS name
   of a website, so the sensitive information indicates browsing history
   at domain granularity.

   Several protocol standards contain elements that protect the user's
   browsing history from a passive adversary.  The DNS over TLS standard
   [RFC7858] allows clients to perform DNS queries without revealing the
   request or response to an attacker.  This allows clients to access
   DNS-named services without publicly revealing the name of the
   services that they are about to access.

   After a DNS lookup, the HTTPS standard [RFC2818] allows clients to
   perform HTTP requests to a server without revealing the contents of
   the HTTP request or response, using TLS.  This hides the website's
Show full document text