Optimistic Encryption using TLS Signaling in the DNS

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2013-10-14
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Additional URLs
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                                         P. Hoffman
Internet-Draft                                            VPN Consortium
Intended status: Standards Track                        October 14, 2013
Expires: April 17, 2014

          Optimistic Encryption using TLS Signaling in the DNS


   Many Internet servers offer content in two transports: unencryped,
   and encrypted with TLS.  A user who accesses some content with a URL
   that indicates unencrypted (such as "http:") might prefer to get the
   content encrypted but doesn't bother to change the URL to indicate
   this.  This proposal allows Internet clients, particularly web
   clients and mail user agents, to do a DNS lookup to see whether they
   might expect content for a particular host to also be available under
   TLS.  Using the DNS for this is much faster than attempting a TLS
   session that might time out or take many round trips in order to
   discover that the content is not available.

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 April 17, 2014.

Copyright Notice

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

Hoffman                  Expires April 17, 2014                 [Page 1]
Internet-Draft             DNS TLS Signaling                October 2013

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The TRYTLS Resource Record  . . . . . . . . . . . . . . . . .   3
   3.  Semantics of the TRYTLS Record  . . . . . . . . . . . . . . .   3
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  Informative References  . . . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   4

1.  Introduction

   Starting a TLS [RFC5246] session takes time and resources, so
   applications tend not to do it unless specifically asked, such as
   when a user enters a "https:" or "imaps:" URL.  The downside of this
   is that some Internet traffic that might be encrypted goes
   unencrypted even when a user might want encryption.

   A classic example of this problem is a web user who cares about
   encrypting as much content as possible and is willing to type URLs
   with "https:", but goes to a web page whose URLs are all "http".
   Some of those pages might be served under either "http:" or "https:",
   but you can't specify both in an HTML page.

   Although most people think of this as a problem for HTTP [RFC2817],
   it also affects mail user agents that use either POP [RFC1939] or
   IMAP [RFC3501].  Although it is uncommon to see "pop:" or "imap:"
   URLs, many applications use them internally.  Allowing servers that
   allow both the unencrypted and encrypted versions of these protocols
   would also go a long way towards encrypting more traffic on the

   A potential solution to this problem is to allow a site operator to
   tell applications that content that is available unencrypted is
   likely to also be available encrypted with TLS.  If the application
   can do a quick check for TLS availability, the application might be
   more willing to risk the setup time for TLS.  This document proposed
   to do that with a new DNS RRtype, TRYTLS, that is a non-binding
   indicator from the site owner that clients that can use TLS coming to
   this domain name are likely to find a TLS server for a particular

Hoffman                  Expires April 17, 2014                 [Page 2]
Internet-Draft             DNS TLS Signaling                October 2013

2.  The TRYTLS Resource Record
Show full document text