idnits 2.17.1 draft-hoffman-trytls-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 10, 2014) is 3659 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft VPN Consortium 4 Intended status: Standards Track April 10, 2014 5 Expires: October 12, 2014 7 Optimistic Encryption using TLS Signaling in the DNS 8 draft-hoffman-trytls-02 10 Abstract 12 Many Internet servers offer content in two transports: unencrypted, 13 and encrypted with TLS. A user who accesses some content with a URL 14 that indicates unencrypted (such as "http:") might prefer to get the 15 content encrypted but doesn't bother to, or can't, change the URL to 16 indicate this. This proposal allows Internet clients, particularly 17 web clients and mail user agents, to do a DNS lookup to see whether 18 they might expect content for a particular host to also be available 19 under TLS. Using the DNS for this is much faster than attempting a 20 TLS session that might time out or take many round trips in order to 21 discover that the content is not available. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 12, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. The TRYTLS Resource Record . . . . . . . . . . . . . . . . . 3 59 3. Semantics of the TRYTLS Record . . . . . . . . . . . . . . . 3 60 4. Comparison to Other Proposals . . . . . . . . . . . . . . . . 4 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 7. Informative References . . . . . . . . . . . . . . . . . . . 4 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 Starting a TLS [RFC5246] session takes time and resources, so 69 applications tend not to do it unless specifically asked, such as 70 when a user enters a "https:" or "imaps:" URL. The downside of this 71 is that some Internet traffic that might be encrypted goes 72 unencrypted even when a user might want encryption. 74 A classic example of this problem is a web user who cares about 75 encrypting as much content as possible and is willing to type URLs 76 with "https:", but goes to a web page whose URLs are all "http". 77 Some of those pages might be served under either "http:" or "https:", 78 but you can't specify both in an HTML page. 80 Although most people think of this as a problem for HTTP [RFC2817], 81 it also affects mail user agents that use either POP [RFC1939] or 82 IMAP [RFC3501]. Although it is uncommon to see "pop:" or "imap:" 83 URLs, many applications use them internally. Allowing servers that 84 allow both the unencrypted and encrypted versions of these protocols 85 would also go a long way towards encrypting more traffic on the 86 Internet. 88 A potential solution to this problem is to allow a site operator to 89 tell applications that content that is available unencrypted is 90 likely to also be available encrypted with TLS. If the application 91 can do a quick check for TLS availability, the application might be 92 more willing to risk the setup time for TLS. This document proposed 93 to do that with a new DNS RRtype, TRYTLS, that is a non-binding 94 indicator from the site owner that clients that can use TLS coming to 95 this domain name are likely to find a TLS server for a particular 96 protocol. 98 An orthogonal solution that applies only to HTTP is "HTTP Alternative 99 Services", [AltSvc]. That proposal allows the server in an existing 100 cleartext HTTP connection to indicate to the client that an alternate 101 service (in this case, TLS) exists, as well as to give its location. 102 The proposal in this document is not meant to be a replacement for 103 HTTP Alternate Services; instead, it allows clients to find out about 104 a pontential TLS server before even sending any cleartext. 106 2. The TRYTLS Resource Record 108 The TRYTLS resource record type, whose value is TBD1, lists the port 109 on which a particular TLS-based service might be found for a given 110 application protocol. 112 The presentation format is: 114 _appname.hostname IN TRYTLS sec-port 116 The application name ("_appname") being queried is taken from a new 117 IANA registry. The initial values for the names in the registry are 118 "_http", "_pop", and "_imap". 120 The secure port number (called "sec-port") is a two-octet positive 121 integer. 123 3. Semantics of the TRYTLS Record 125 The lack of a TRYTLS record in a zone implies absolutely nothing. 127 The presence of a TRYTLS record for a particular application type 128 indicates that there is likely to be a server for that protocol, 129 running under TLS, at the port number given. There is absolutely no 130 guarantee that such a server exists, or that the TLS server's 131 certificate will be trusted by any particular client. If the record 132 exists, the port number in the response is the port number a client 133 should use to access the server over TLS. 135 The presence of a TRYTLS record for HTTP (such as 136 "_http.www.example.com") indicates that some HTTP origins which have 137 the given hostname will also be available over TLS. The presence of 138 such a record does not indicate that all origins, or all specific 139 URLs that include those origins, will be served under TLS. 141 The existence or absence of a TRYTLS record does not have any effect 142 on other ways of discovering whether there is a TLS service for a 143 particular application. 145 4. Comparison to Other Proposals 147 Some people interpret the DANE TLSA RRtype [RFC6698] as indicating 148 that TLS is available for HTTP at a particular hostname, even though 149 this interpretation is not part of the specification. Such an 150 indication is being discussed in the DANE WG. The TRYTLS differs 151 from TLSA in that TRYTLS does not need to be protected by DNSSEC. 152 Thus, doing a TRYTLS lookup is available to all clients, not just 153 those with their own validating DNS resolvers or secure connections 154 to such resolvers. However, doing a successful TLSA lookup will lead 155 to the client also having a much stronger trust of the eventual TLS 156 session because the client will also have the TLS trust anchor or end 157 entity certificate validated through the DNSSEC trust chain. 159 An earlier Internet-Draft, draft-hoffman-server-has-tls, tried to 160 combine the semantics of the TRYTLS record with the idea of a server- 161 provided policy for fallback. That draft has been abandoned because 162 the IETF community could not come to any agreement on whether such a 163 fallback policy was a good or terrible idea. 165 5. IANA Considerations 167 ** Insert DNS RRtype template here for TRYTLS that assigns TBD1. ** 169 ** Create a new registry for _appname ** 171 6. Security Considerations 173 There is a general positive security effect on the Internet when more 174 traffic is encrypted. There are probably some exceptions to this 175 statement, and probably some people who would say that the effect is 176 much more positive than "general". 178 There is no reason to require TRYTLS to be protected by DNSSEC. An 179 attacker who adds a TRYTLS record when TLS is not available will 180 cause a slight denial-of-service attack, but one that is not much 181 worse than the case today where a client might try a TLS connection 182 anyway. 184 7. Informative References 186 [AltSvc] Nottingham, M., McManus, P., and J. Reschke, "HTTP 187 Alternative Services", draft-ietf-httpbis-alt-svc (work in 188 progress), 2014. 190 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 191 STD 53, RFC 1939, May 1996. 193 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/ 194 1.1", RFC 2817, May 2000. 196 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 197 4rev1", RFC 3501, March 2003. 199 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 200 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 202 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 203 of Named Entities (DANE) Transport Layer Security (TLS) 204 Protocol: TLSA", RFC 6698, August 2012. 206 Author's Address 208 Paul Hoffman 209 VPN Consortium 211 Email: paul.hoffman@vpnc.org