idnits 2.17.1 draft-agl-tls-nextprotoneg-03.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 'Intended status' indicated for this document; assuming Proposed Standard 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 24, 2012) is 4378 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: 'ChangeCipherSpec' is mentioned on line 156, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Langley 3 Internet-Draft Google Inc 4 Expires: October 26, 2012 April 24, 2012 6 Transport Layer Security (TLS) Next Protocol Negotiation Extension 7 draft-agl-tls-nextprotoneg-03 9 Abstract 11 This document describes a Transport Layer Security (TLS) extension 12 for application layer protocol negotiation. This allows the 13 application layer to negotiate which protocol should be performed 14 over the secure connection. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on October 26, 2012. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 52 3. Next Protocol Negotiation Extension . . . . . . . . . . . . . 5 53 4. Protocol selection . . . . . . . . . . . . . . . . . . . . . . 8 54 5. Design discussion . . . . . . . . . . . . . . . . . . . . . . 9 55 6. Security considerations . . . . . . . . . . . . . . . . . . . 10 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 57 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 58 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 59 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 60 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 63 1. Introduction 65 The Next Protocol Negotiation extension (NPN) is currently used to 66 negotiate the use of SPDY [spdy] as an application level protocol on 67 port 443, and to perform SPDY version negotiation. However, it is 68 not SPDY specific in any way. 70 Designers of new application level protocols are faced with a 71 problem: there are no good options for establishing a clean transport 72 for a new protocol and negotiating its use. Negotiations on port 80 73 will run afoul of intercepting proxies. Ports other than 80 and 443 74 are likely to be firewalled without any fast method of detection, and 75 are also unlikely to traverse HTTP proxies with CONNECT. Negotiating 76 on port 443 is possible, but may run afoul of MITM proxies and also 77 uses a round trip for negotiation on top of the round trips for 78 establishing the TLS connection. Negotiation at that level is also 79 dependent on the application level protocol, i.e. the real world 80 tolerance of servers to HTTP Upgrade requests. 82 Next Protocol Negotiation allows application level protocols to be 83 negotiated without additional round trips and with clean fallback in 84 the case of an unsupportive MITM proxy. 86 2. Requirements Notation 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 3. Next Protocol Negotiation Extension 94 A new extension type ("next_protocol_negotiation(13172)") is defined 95 and MAY be included by the client in its "ClientHello" message. If, 96 and only if, the server sees this extension in the "ClientHello", it 97 MAY choose to echo the extension in its "ServerHello". 99 enum { 100 next_protocol_negotiation(13172), (65535) 101 } ExtensionType; 103 The "extension_data" field of a "next_protocol_negotiation" extension 104 in a "ClientHello" MUST be empty. 106 The "extension_data" field of a "next_protocol_negotiation" extension 107 in a "ServerHello" contains an optional list of protocols advertised 108 by the server. Protocols are named by opaque, non-empty byte strings 109 and the list of protocols is serialized as a concatenation of 8-bit, 110 length prefixed byte strings. Implementations MUST ensure that the 111 empty string is not included and that no byte strings are truncated. 113 A new handshake message type ("next_protocol(67)") is defined. If, 114 and only if, the server included a "next_protocol_negotiation" 115 extension in its "ServerHello" message, the client MUST send a 116 "NextProtocol" message after its "ChangeCipherSpec" and before its 117 "Finished" message. 119 enum { 120 next_protocol(67), (65535) 121 } HandshakeType; 123 Therefore a full handshake with "NextProtocol" has the following flow 124 (contrast with section 7.3 of RFC 5246 [RFC5246]): 126 Client Server 128 ClientHello (NPN extension) --------> 129 ServerHello 130 (NPN extension & 131 list of protocols) 132 Certificate* 133 ServerKeyExchange* 134 CertificateRequest* 135 <-------- ServerHelloDone 136 Certificate* 137 ClientKeyExchange 138 CertificateVerify* 139 [ChangeCipherSpec] 140 NextProtocol 141 Finished --------> 142 [ChangeCipherSpec] 143 <-------- Finished 144 Application Data <-------> Application Data 146 An abbreviated handshake with "NextProtocol" has the following flow: 148 Client Server 150 ClientHello (NPN extension) --------> 151 ServerHello 152 (NPN extension & 153 list of protocols) 154 [ChangeCipherSpec] 155 <-------- Finished 156 [ChangeCipherSpec] 157 NextProtocol 158 Finished --------> 159 Application Data <-------> Application Data 161 The "NextProtocol" message has the following format: 163 struct { 164 opaque selected_protocol<0..255>; 165 opaque padding<0..255>; 166 } NextProtocol; 168 The contents of "selected_protocol" are an opaque protocol string, 169 but need not have been advertised by the server. The length of 170 "padding" SHOULD be 32 - ((len(selected_protocol) + 2) % 32). Note 171 that len(selected_protocol) does not include its length prefix. 173 Unlike many other TLS extensions, this extension does not establish 174 properties of the session, only of the connection. When session 175 resumption or session tickets [RFC5077] are used, the previous 176 contents of this extension are irrelevant and only the values in the 177 new handshake messages are considered. 179 For the same reasons, after a handshake has been performed for a 180 given connection, renegotiations on the same connection MUST NOT 181 include the "next_protocol_negotiation" extension. 183 4. Protocol selection 185 It's expected that a client will have a list of protocols that it 186 supports, in preference order, and will only select a protocol if the 187 server supports it. In that case, the client SHOULD select the first 188 protocol advertised by the server that it also supports. In the 189 event that the client doesn't support any of server's protocols, or 190 the server doesn't advertise any, it SHOULD select the first protocol 191 that it supports. 193 There may be cases where the client knows, via other means, that a 194 server supports an unadvertised protocol. In these cases the client 195 can simply select that protocol. 197 5. Design discussion 199 NPN is an outlier from TLS in several respects: firstly that it 200 introduces a handshake message between the "ChangeCipherSpec" and 201 "Finished" message, that the handshake message is padded, and that 202 the negotiation isn't done purely with the hello messages. All these 203 aspects of the protocol are intended to prevent middle-ware 204 discrimination based on the negotiated protocol and follow the 205 general principle that anything that can be encrypted, should be 206 encrypted. The server's list of advertised protocols is in the clear 207 as a compromise between performance and robustness. 209 6. Security considerations 211 The server's list of supported protocols is still advertised in the 212 clear with this extension. This may be undesirable for certain 213 protocols (such as Tor [tor]) where one could imagine that hostile 214 networks would terminate any TLS connection with a server that 215 advertised such a capability. In this case, clients may wish to 216 opportunistically select a protocol that wasn't advertised by the 217 server. However, the workings of such a scheme are outside the scope 218 of this document. 220 7. IANA Considerations 222 This document requires IANA to update its registry of TLS extensions 223 to assign entry 13172 as "next_protocol_negotiation". 225 This document also requires IANA to update its registry of TLS 226 handshake types to assign entry 67 as "next_protocol". 228 This document also requires IANA to create a registry of TLS Next 229 Protocol Negotiation protocol strings on a first come, first served 230 basis, initially containing the following entries: 232 o "http/1.1": HTTP/1.1 [RFC2616] 234 o "spdy/1": (obsolete) SPDY version 1 236 o "spdy/2": SPDY version 2 238 o "spdy/3": SPDY version 3 240 8. Acknowledgments 242 This document benefited specifically from discussions with Wan-Teh 243 Chang and Nagendra Modadugu. 245 9. References 247 9.1. Normative References 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, March 1997. 252 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 253 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 255 9.2. Informative References 257 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 258 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 259 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 261 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 262 "Transport Layer Security (TLS) Session Resumption without 263 Server-Side State", RFC 5077, January 2008. 265 [tor] Dingledine, R., Matthewson, N., and P. Syverson, "Tor: The 266 Second-Generation Onion Router", August 2004. 268 [spdy] Belshe, M. and R. Peon, "SPDY Protocol (Internet Draft)", 269 Feb 2012. 271 Author's Address 273 Adam Langley 274 Google Inc 276 Email: agl@google.com