idnits 2.17.1 draft-hoffman-server-has-tls-05.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 8, 2011) is 4607 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) == Missing Reference: 'RFC3597' is mentioned on line 336, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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 September 8, 2011 5 Expires: March 11, 2012 7 Specifying That a Server Supports TLS 8 draft-hoffman-server-has-tls-05 10 Abstract 12 A server that hosts applications that can be run with or without TLS 13 may want to communicate with clients whether the server is hosting an 14 application only using TLS or also hosting the application without 15 TLS. Many clients have a policy to try to set up a TLS session but 16 fall back to insecure if the TLS session cannot be set up. If the 17 server can securely communicate whether or not it can fall back to 18 insecure tells such a client whether or not they should even try to 19 set up an insecure session with the server. This document describes 20 the use cases for this type of communication and a secure method for 21 communicating that information. 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 March 11, 2012. 40 Copyright Notice 42 Copyright (c) 2011 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 1. Introduction 57 Most client-server applications standardized in the IETF have two 58 modes: an insecure mode that involves no authentication or integrity 59 protection, and a secure mode that requires (at a minimum) that the 60 client authenticate the server and set up a communication channel 61 with integrity protection. In most cases, the secure mode is 62 achieved by starting a TLS [RFC5246] session and, when successful, 63 running the insecure mode inside of it. 65 People within the IETF and application developers have historically 66 had widely varying views on what a client should and should not do 67 about the two modes. Phrases like "assured security" and "client 68 flexibility" are used, often without clear definition. Deployed 69 clients and servers from different vendors act differently for the 70 two modes, often relegating the control of the two modes to 71 "advanced" configuration options (if such control is given to the 72 user at all). 74 Section 2 of this document lays out the choices for clients and 75 servers for handling the two modes in different circumstances, and 76 gives specific semantics for each type of client and server. Section 77 3 gives a protocol for a domain owner to specify whether they offer 78 one or both modes for any given application, and to specify a client 79 policy preference. Section 4 defines how to implement various 80 policies using the protocol. Using the protocol given here, a server 81 can completely specify what it offers and allows a client to reliably 82 choose which mode it wants to use. 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [RFC2119]. 88 2. Security Options for Clients and Servers 90 This section describes the different types of clients and servers 91 that deal with insecure protocols that can be secured by wrapping the 92 protocol in TLS. It also describes the types of security policies 93 that those clients and servers can embody. It explicitly does not 94 argue that one policy is better than another in any particular 95 environment; instead, it assumes that the server operator and the 96 client implementor (and, hopefully, the human operating the client) 97 can make that decision themselves if given the proper tools. 99 This discussion assumes a client-server protocol that is defined for 100 an insecure fashion, and is also defined for a secure fashion that 101 uses a TLS session for security. For example, "HTTP run over port 102 80" and "HTTP-in-TLS run over port 443" would meet this definition; 103 "SMTP without STARTTLS" and "SMTP with STARTTLS" (see [RFC3207]) 104 would also meet this definition. Some peer-to-peer protocols might 105 meet this definition if the startup actions resemble the typical 106 client-server interaction, but this discussion makes no extra attempt 107 to cover such protocols. 109 Given a particular client application configuration, there are three 110 interesting types of clients: 112 Insecure Only (CIO) -- The client is configured to only attempt 113 communication for the application in its insecure form. For 114 example, a POP client might be configured to only try insecure POP 115 on port 110. 117 Secure Only (CSO) -- The client is configured to only attempt 118 communication for the application in its secure, TLS-wrapped form. 119 For example, a POP client might be configured to only try secure 120 POP on port 995. 122 Allows Fallback From Secure to Insecure (CFB) -- The client is 123 configured to attempt communication for the application in its 124 secure, TLS-wrapped form, but if it fails to set up a TLS session, 125 the client will attempt to attempt communication to the same 126 server using the insecure form. This configuration may be offered 127 for reasons such as if the client doesn't trust the CA that the 128 server uses to identify itself. 130 Given a particular server configuration, there are three interesting 131 types of servers: 133 Insecure Only (SIO) -- The server responds without TLS on the main 134 port for the application. A host for a web server that only 135 responds to HTTP requests on port 80 is an example of this. 137 Secure Only (SSO) -- The server responds using TLS on the TLS- 138 specific port for the application. For example, a host for a web 139 server only responds to HTTP requests on port 443. Alternately, 140 if the application supports in-band security update (such as 141 STARTTTLS for SMTP), the server responds on the normal port, tries 142 to establish a TLS session, and does not proceed with the protocol 143 if a TLS session cannot be established. 145 Serves Both Secure and Insecure (SSB) -- The server responds 146 without TLS on the main port for the application *and* responds 147 using TLS on the TLS-specific port for the application, such as 148 both ports 80 and 443 for HTTP. Alternately, if the application 149 supports in-band security update (such as STARTTTLS for SMTP), the 150 server responds on the normal port, tries to establish a TLS 151 session, and proceeds with the normal protocol if a TLS session 152 cannot be established. 154 It is expected that client configuration will be per-host. That is, 155 a client that is CSO for some hosts might be CFB for other hosts. 156 The server configuration, of course, applies to all clients accessing 157 it. 159 In this taxonomy, a CIO can always communicate with an SIO and SSB. 160 A CSO can communicate with an SSO, and can communicate with an SSB as 161 long as the TLS session is set up successfully. A CFB can 162 communicate with an SIO, an SSO, and an SSB. 164 Given this, a host that only allows clients to use the secure form of 165 a protocol MUST only be configured to be SSO; a client that wants to 166 only communicate with a server securely MUST only be configured to be 167 CSO. 169 Note that a host might want to serve both insecure and secure form of 170 a protocol, but wants clients to only use the secure form. For 171 example, the insecure form might immediately do an upgrade to the 172 secure form, or it might do a protocol-based redirection to a server 173 doing the secure form. Such a host will want to be able to indicate 174 that, even if it has both secure and insecure ports for a protocol 175 open, it wants clients that can be configured as CFB or CSO to only 176 be configured as CSO. 178 This taxonomy exposes a problem with the way that clients and servers 179 interact today: a CIO that starts an insecure communication with a 180 server, or a CFB that falls back to insecure communication with a 181 server, has no idea whether the site they wish to communication with 182 even hosts an insecure server. The server might be configured to be 183 any of SIO or SSO or SSB, but the client cannot tell. If a CIO or 184 CFB client knows ahead of time that a host did not support insecure 185 communication, the client would not even start communication because 186 it would either just waste time waiting for a timeout, or it would 187 communicate with an impostor. 189 Note that the protocol described here is not a discovery protocol. 190 It is perfectly reasonable for a server to be running a service in an 191 insecure fashion, a secure fashion, or both, without using the 192 protocol that is described here. The purpose of the protocol is to 193 let a client find out, securely, whether a particular server protocol 194 is being run securely, not whether it is being run at all. 196 3. The HASTLS Resource Record 198 The HASTLS resource record type, whose value is TBD1, lists an 199 insecure/secure port pair that is served on the host named by the 200 domain name for the application and protocol given in the query. It 201 only applies to applications that are secured with TLS, not to 202 applications that have insecure and secure versions that use some 203 other security protocol. 205 The presentation format is: 207 _appname._protoname.hostname IN HASTLS ins-port sec-port pol-pref 209 The application name ("appname") and protocol name ("protoname") 210 being queried are the same as are used in the SRV RRtype described in 211 [RFC2782] The insecure port number (called "ins-port"), the secure 212 port number (called "sec-port"), and the client policy preference 213 (called "pol-pref") are each two-octet positive integers. 215 If a server does not offer one of the the two services, that service 216 is indicated by port 0. For protocols that use in-band signaling for 217 security upgrades, "ins-port" and "sec-port" have the same value. A 218 HASTLS record MUST NOT have both the "ins-port" and "sec-port" set to 219 0. 221 A query for a particular application MAY return more than one HASTLS 222 resource record, and conformant clients MUST be able to process 223 multiple responses from a single query. For example, a site that 224 offers HTTP on both port 80 and port 8080 might return two records, 225 one for port 80 and its secure counterpart (if any), and one for 226 protport 8080 and its secure counterpart (if any). 228 The HASTLS record is not useful for service discovery. Clients MUST 229 NOT make any assumptions about an application for which there is not 230 a HASTLS record; the lack of a HASTLS record for a particular 231 application says nothing about whether or not the service is offered 232 on the host on a specific port. 234 The client policy preference octet specifies the host's preference 235 for client policy. It has two possible values: 237 0 -- The host's administrator has no client policy preference for 238 this protocol. 240 1 -- If the client could be configured as either CFB or CSO for 241 this protocol, and the host's administrator was able to configure 242 the client for the protocol, that administrator would configure 243 the client as CSO. Stated another way, the host's administrator 244 does not want any CFB client to access the host for this protocol. 246 Note that specifying 1 for the client policy preference when a host 247 does not support a protocol securely makes no sense, but it also does 248 no harm. Further, for a host that is SSO, both policy preferences 249 have an identical result. 251 For example, the server at www.example.com offers SMTP both securely 252 and insecurely. The host's SMTP administrator has a client policy 253 preference that CFB clients not access the host. The HASTLS record 254 would look like: 256 _smtp._tcp.www.example.com IN HASTLS 25 25 1 258 Another example is the server at www.example.com offering HTTP only 259 securely. The resulting HASTLS records could be either: 261 _http._tcp.www.example.com IN HASTLS 0 443 0 262 or 263 _http._tcp.www.example.com IN HASTLS 0 443 1 265 [[ NEED TO ADD: wire format. ]] 267 4. Implementing Policy with HASTLS 269 Servers that have a policy to declare the server as SIO, SSO, or SSB 270 can use HASTLS to announce that policy for each application it 271 serves. A server whose policy is that it is an SIO would set the 272 ins-port to a non-zero number and the sec-port to 0. A server whose 273 policy is that it is an SSO would set the ins-port to 0 and the sec- 274 port to a non-zero number. A server whose policy is that it is an 275 SSB would set both the ins-port and sec-port to a non-zero number. 277 The conformance requirements for a client using the HASTLS record 278 depend on the policy configured for the client or the server: 280 o A client communicating with a server that has set its client 281 policy preference to 1 MUST NOT try to communicate insecurely with 282 that server, even if the server has set the ins-port to a non-zero 283 number; this is the equivalent of temporarily setting its policy 284 for the server to CSO for that application. This temporary policy 285 based on the server's client policy preference overrides any 286 others for the server. 288 o A client whose policy is that it is a CIO MUST NOT try to 289 communicate insecurely with a server that has the ins-port set to 290 0. 292 o A client whose policy is that it is a CSO MUST only try to 293 communicate securely with a server that has the sec-port set to a 294 non-zero number. 296 o A client whose policy is that it is a CSO MUST NOT try to 297 communicate with the server if an ins-port value is given. 299 o A client whose policy is that it is a CFB MUST NOT try to 300 communicate securely with a server that has the sec-port set to 0. 302 o A client whose policy is that it is a CFB MUST NOT try to 303 communicate insecurely with a server that has the ins-port set to 304 0. 306 o A client whose policy is that it is a CFB trying to communicate 307 with a server whose sec-port is set to a non-zero number SHOULD 308 first try to communicate securely over the secure port unless it 309 knows from other sources that the TLS session will not be set up 310 properly. 312 5. IANA Considerations 314 This document requests that IANA allocate a new DNS resource record 315 type called HASTLS from the data types range; it will have the value 316 TBD1. 318 Submission template: 320 A. Submission Date: Date of this document 321 B. Submission Type: New RRTYPE 322 C. Contact Information for submitter: Author of this document 323 D. Motivation for the new RRTYPE application: Contents of 324 this document 325 E. Description of the proposed RR type: Contents of this document 326 F. What existing RRTYPE or RRTYPEs come closest to filling that 327 need and why are they unsatisfactory: None are even close to 328 that given in this document. 329 G. What mnemonic is requested for the new RRTYPE (optional): 330 HASTLS 331 H. Does the requested RRTYPE make use of any existing IANA 332 Registry or require the creation of a new IANA sub-registry in 333 DNS Parameters: No 334 I. Does the proposal require/expect any changes in DNS 335 servers/resolvers that prevent the new type from being 336 processed as an unknown RRTYPE (see [RFC3597]): No 337 J. Comments: None 339 6. Security Considerations 341 In order to prevent a man-in-the-middle (MITM) attack where the 342 attacker can change DNS responses, the data in the HASTLS record 343 needs to be received securely by a DNS requester, such as through 344 validated DNSSEC. At this time, there is no common method for a 345 application client to know whether or not the data it receives from 346 the DNS has been protected with DNSSEC unless that application has a 347 validating resolver, or has an API to the operating system and the 348 operating system has a validating resolver. 350 Some MITM attacks can do a partial impersonation of the secure server 351 if the client does not have good indications when an SSL connection 352 is established (see, especially, the "sslstrip" attack described in 353 various places in 2009). This protocol cannot protect against all 354 such attacks because the attack is actually on the user interface, 355 not the security of the TLS connection. 357 If the HASTLS information is received by the client system without 358 security, an attacker could change the HASTLS information to fool the 359 client into thinking that a host provides insecure application 360 services and/or does not provide secure application services. Thus, 361 cryptographic protection of the contents of the HASTLS information 362 (such as with DNSSEC) is mandatory. 364 7. References 365 7.1. Normative References 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, March 1997. 370 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 371 specifying the location of services (DNS SRV)", RFC 2782, 372 February 2000. 374 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 375 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 377 7.2. Informative References 379 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 380 Transport Layer Security", RFC 3207, February 2002. 382 Appendix A. Protocols That Have Both Second Ports and Upgrade Paths 384 There is a significant open issue with the current proposal: some 385 protocols (hopefully few) have multiple ways of using TLS. One that 386 was mentioned is HTTP, which has both "start TLS on TCP port 443" and 387 "use STARTTLS on TCP port 80 as described in RFC 2817". POP and IMAP 388 have the same issue. 390 One possibility is for this protocol to say "always use the second 391 port" or "always use in-stream upgrade". This would give the client 392 unambiguous instructions, but would not work for servers that do not 393 implement the specified option. 395 Another possibility is to have the HASTLS response indicate which way 396 the secure version is supported. This is more flexible than the 397 first proposal, but also more complicated for the client. It also is 398 possibly overkill if there are only two or three protocols of 399 interest. 401 This issue needs to be resolved before the proposal is finished. 403 Author's Address 405 Paul Hoffman 406 VPN Consortium 408 Email: paul.hoffman@vpnc.org