Internet DRAFT - draft-hoffman-trytls

draft-hoffman-trytls







Network Working Group                                         P. Hoffman
Internet-Draft                                            VPN Consortium
Intended status: Standards Track                          April 10, 2014
Expires: October 12, 2014


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

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, or can't, 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 October 12, 2014.

Copyright Notice

   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



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


   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 . . . . . . . . . . . . . . . .   4
   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 October 12, 2014                [Page 2]

Internet-Draft              DNS TLS Signaling                 April 2014


   An orthogonal solution that applies only to HTTP is "HTTP Alternative
   Services", [AltSvc].  That proposal allows the server in an existing
   cleartext HTTP connection to indicate to the client that an alternate
   service (in this case, TLS) exists, as well as to give its location.
   The proposal in this document is not meant to be a replacement for
   HTTP Alternate Services; instead, it allows clients to find out about
   a pontential TLS server before even sending any cleartext.

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.





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


4.  Comparison to Other Proposals

   Some people interpret the DANE TLSA RRtype [RFC6698] as indicating
   that TLS is available for HTTP at a particular hostname, even though
   this interpretation is not part of the specification.  Such an
   indication is being discussed in the DANE WG.  The TRYTLS differs
   from TLSA in that TRYTLS does not need to be protected by DNSSEC.
   Thus, doing a TRYTLS lookup is available to all clients, not just
   those with their own validating DNS resolvers or secure connections
   to such resolvers.  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 or end
   entity certificate 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.

7.  Informative References

   [AltSvc]   Nottingham, M., McManus, P., and J. Reschke, "HTTP
              Alternative Services", draft-ietf-httpbis-alt-svc (work in
              progress), 2014.

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




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


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

   [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 October 12, 2014                [Page 5]