idnits 2.17.1 draft-agl-tls-nextproto-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 258 lines 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 (May 14, 2011) is 4732 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 normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 Intended status: Standards Track P. Hoffman 5 Expires: November 15, 2011 VPNC 6 May 14, 2011 8 Transport Layer Security (TLS) Next Protocol Extension 9 draft-agl-tls-nextproto-00 11 Abstract 13 This document describes a Transport Layer Security (TLS) extension 14 for application layer protocol probing and announcement. This allows 15 the application client to specify which protocol will be performed 16 over the secure connection. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 15, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction 53 1.1. Design of the Protocol 54 2. Requirements Notation 55 3. Next Protocol Extension 56 3.1. Handshake Summary 57 3.2. Session Resumption and Renegotiation 58 4. Security Considerations 59 5. IANA Considerations 60 6. Acknowledgements 61 7. References 62 7.1. Normative References 63 7.2. Informative References 64 Authors' Addresses 66 1. Introduction 68 As the Internet has evolved, it has become commonplace for hosts to 69 initiate connections based on untrusted and possibly hostile data. 70 HTTP [RFC2616] clients are currently the most widespread example of 71 this as they will fetch URLs based on the contents of untrusted 72 webpages. 74 Any time that a connection is initiated based on untrusted data there 75 is the possibility of a cross-protocol attack. If the attacker can 76 control the contents of the connection in any way (for example, the 77 requested URL in an HTTP connection) they may be able to encode a 78 valid message in another protocol. The connecting host believes that 79 it is speaking one protocol but the server understands it to be 80 another. The application of Postel's Law exacerbates the issue as 81 many servers will permit gross violations of the expected protocol in 82 order to achieve maximum compatibility with clients. 84 The WebSockets [websockets] protocol seeks to allow low-latency, 85 full-duplex communication between browsers and HTTP servers. 86 However, it also permits an unprecedented amount of attacker control 87 over the contents of the connection. In order to prevent cross- 88 protocol attacks, a mechanism to assure that both client and server 89 are speaking the same protocol is required. To this end, the Next 90 Protocol extension described in this document extends the TLS 91 [RFC5246] handshake to allow the client to tell the server the 92 intended application protocol. 94 1.1. Design of the Protocol 96 The basic design of the extension is that the client expresses that 97 it knows how to specify which application protocol it will use after 98 the TLS session is established. The server responds with some or all 99 the types of application protocols that it knows. The client 100 responds with the protocol that it intends to use; this might even be 101 one that was not listed by the server. 103 Note that this protocol is not a negotiation in the classic sense of 104 "client says what it wants and server picks one choice". Instead, it 105 allows the client to not reveal in the clear which application 106 protocol it intends to use after TLS is established. Intermediaries 107 who might prevent TLS from being established for a particular 108 application cannot determine which protocol will be used; this, in 109 turn, leads to secure connections for more protocols. 111 2. Requirements Notation 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 3. Next Protocol Extension 119 This document defines a new extension type, "next_protocol(TBD)". 121 enum { 122 next_protocol(TBD), (65535) 123 } ExtensionType; 125 The next_protocol extension MAY be included by the client in its 126 "ClientHello" message. If, and only if, the server sees this 127 extension in the "ClientHello", it MAY choose to include the 128 extension in its "ServerHello". 130 The "extension_data" field of a "next_protocol" in a "ClientHello" 131 MUST be empty. The "extension_data" field of a "next_protocol" in a 132 "ServerHello" contains the list of application-layer protocols that 133 the server wishes to advertise that it supports. That list is a set 134 of two-octet (uint16) values, in network byte order, taken from the 135 ports numbers assigned by IANA; see 136 . 138 This document also defines a new handshake message type, 139 "next_protocol_ann(TBD)"). 141 struct { 142 uint16 announced_protocol; 143 } NextProtocolAnnounce; 145 If, and only if, the server included a "next_protocol" extension in 146 its ServerHello message, the client MUST send a 147 "NextProtocolAnnounce" message after its "ChangeCipherSpec" and 148 before its "Finished" message. The NextProtocolAnnounce message 149 contains the single application-layer protocol that the client will 150 use in this connection after the TLS handshake completes; that value 151 does not need to match any of those given by the server in the 152 next_protocol extension. 154 3.1. Handshake Summary 156 -> ClientHello (contains next_protocol extension 157 with empty extension_data ) 158 <- ServerHello (contains next_protocol extension 159 with list of protocols) 160 <- ... 161 <- ServerHelloDone 162 -> ClientKeyExchange 163 -> ... 164 -> ChangeCipherSpec 165 -> NextProtocolAnnounce (contains announced_protocol) 166 -> Finished 167 <- ChangeCipherSpec 168 <- Finished 170 3.2. Session Resumption and Renegotiation 172 Unlike many other TLS extensions, this extension does not establish 173 properties of the session, only of the connection. When session 174 resumption or session tickets [RFC5077] are used, the previous 175 contents of this extension are irrelevant and only the values in the 176 new handshake messages are considered. 178 For the same reasons, after a handshake has been performed for a 179 given connection, renegotiations on the same connection MUST NOT 180 include the "next_protocol" extension. 182 4. Security Considerations 184 This extension sends the server's list of supported protocols in the 185 clear. This may be undesirable for certain protocols (such as Tor 186 [tor]) where one could imagine that hostile networks would terminate 187 any TLS connection with a server that advertised such a capability. 188 Thus, if a client knows through out-of-band methods that a server 189 supports a particular protocol, it can specify that protocol in the 190 NextProtocolAnnounce message and use that protocol after TLS is set 191 up. 193 5. IANA Considerations 195 This document requires IANA to update its registry of TLS extensions 196 to assign an entry, referred herein as "next_protocol". 198 This document also requires IANA to update its registry of TLS 199 handshake types to assign an entry, referred herein as 200 "next_protocol_ann". 202 6. Acknowledgements 204 This document benefitted specifically from discussions with Wan-Teh 205 Chang and Nagendra Modadugu. 207 7. References 209 7.1. Normative References 211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 212 Requirement Levels", BCP 14, RFC 2119, March 1997. 214 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 215 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 216 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 218 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 219 "Transport Layer Security (TLS) Session Resumption without 220 Server-Side State", RFC 5077, January 2008. 222 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 223 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 225 7.2. Informative References 227 [websockets] 228 Fette, I., "The Web Socket protocol", 229 draft-ietf-hybi-thewebsocketprotocol (work in progress), 230 2011. 232 [tor] "Tor Onion Router", www.tor.org , 2011. 234 Authors' Addresses 236 Adam Langley 237 Google Inc 239 Email: agl@google.com 241 Paul Hoffman 242 VPNC 244 Email: paul.hoffman@vpnc.org