Skip to main content

Optimistic Encryption using TLS Signaling in the DNS
draft-hoffman-trytls-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Paul E. Hoffman
Last updated 2013-10-15
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-hoffman-trytls-01
Network Working Group                                         P. Hoffman
Internet-Draft                                            VPN Consortium
Intended status: Standards Track                        October 15, 2013
Expires: April 18, 2014

          Optimistic Encryption using TLS Signaling in the DNS
                        draft-hoffman-trytls-01

Abstract

   Many Internet servers offer content in two transports: unencrypted,
   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 18, 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 18, 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.  Comparison to Other Proposals . . . . . . . . . . . . . . . .   3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

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
   Internet.

   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
   protocol.

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

2.  The TRYTLS Resource Record

   The TRYTLS resource record type, whose value is TBD1, lists the port
   on which a particular TLS-based service might be found for a given
   application protocol.

   The presentation format is:

   _appname.hostname IN TRYTLS sec-port

   The application name ("_appname") being queried is taken from a new
   IANA registry.  The initial values for the names in the registry are
   "_http", "_pop", and "_imap".

   The secure port number (called "sec-port") is a two-octet positive
   integer.

3.  Semantics of the TRYTLS Record

   The lack of a TRYTLS record in a zone implies absolutely nothing.

   The presence of a TRYTLS record for a particular application type
   indicates that there is likely to be a server for that protocol,
   running under TLS, at the port number given.  There is absolutely no
   guarantee that such a server exists, or that the TLS server's
   certificate will be trusted by any particular client.  If the record
   exists, the port number in the response is the port number a client
   should use to access the server over TLS.

   The presence of a TRYTLS record for HTTP (such as
   "_http.www.example.com") indicates that some HTTP origins which have
   the given hostname will also be available over TLS.  The presence of
   such a record does not indicate that all origins, or all specific
   URLs that include those origins, will be served under TLS.

   The existence or absence of a TRYTLS record does not have any effect
   on other ways of discovering whether there is a TLS service for a
   particular application.

4.  Comparison to Other Proposals

   Two recent Internet-Drafts, draft-nottingham-http2-encryption and
   draft-nottingham-httpbis-alt-svc, propose a different method to make
   information similar to the TRYTLS record available, but instead uses
   a header in the HTTP response.

   Some people interpret the DANE TLSA RRtype [RFC6698] as indicating
   that TLS is available for HTTP at a particular hostname, even though

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

   this interpretation is not part of the specification.  If if this
   were to be added to the TLSA spec, the TRYTLS differs from TLSA in
   that TRYTLS does not need to be protected by DNSSEC.  Thus, doing a
   TRYTLS lookup is much faster than a TLSA lookup.  However, doing a
   successful TLSA lookup will lead to the client also having a much
   stronger trust of the eventual TLS session because the client will
   also have the TLS trust anchor validated through the DNSSEC trust
   chain.

   An earlier Internet-Draft, draft-hoffman-server-has-tls, tried to
   combine the semantics of the TRYTLS record with the idea of a server-
   provided policy for fallback.  That draft has been abandoned because
   the IETF community could not come to any agreement on whether such a
   fallback policy was a good or terrible idea.

5.  IANA Considerations

   ** Insert DNS RRtype template here for TRYTLS that assigns TBD1.  **

   ** Create a new registry for _appname **

6.  Security Considerations

   There is a general positive security effect on the Internet when more
   traffic is encrypted.  There are probably some exceptions to this
   statement, and probably some people who would say that the effect is
   much more positive than "general".

   There is no reason to require TRYTLS to be protected by DNSSEC.  An
   attacker who adds a TRYTLS record when TLS is not available will
   cause a slight denial-of-service attack, but one that is not much
   worse than the case today where a client might try a TLS connection
   anyway.  ((( More thinking about this is needed.  )))

7.  Informative References

   [RFC1939]  Myers, J.G. and M.T. Rose, "Post Office Protocol - Version
              3", STD 53, RFC 1939, May 1996.

   [RFC2817]  Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/
              1.1", RFC 2817, May 2000.

   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, March 2003.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

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

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, August 2012.

Author's Address

   Paul Hoffman
   VPN Consortium

   Email: paul.hoffman@vpnc.org

Hoffman                  Expires April 18, 2014                 [Page 5]