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]