idnits 2.17.1 draft-agl-tls-nextprotoneg-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (March 30, 2011) is 4766 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: 4 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 Expires: October 1, 2011 March 30, 2011 6 Transport Layer Security (TLS) Next Protocol Negotiation Extension 7 draft-agl-tls-nextprotoneg-02 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 to IETF 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), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 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 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on October 1, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 58 3. Next Protocol Negotiation Extension . . . . . . . . . . . . . 5 59 4. Security considerations . . . . . . . . . . . . . . . . . . . 6 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 64 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 65 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 10 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 70 As the Internet has evolved, it has become commonplace for hosts to 71 initiate connections based on untrusted and possibly hostile data. 72 HTTP [RFC2616] clients are currently the most widespread example of 73 this as they will fetch URLs based on the contents of untrusted 74 webpages. 76 Any time that a connection is initiated based on untrusted data there 77 is the possibility of a cross-protocol attack. If the attacker can 78 control the contents of the connection in any way (for example, the 79 requested URL in an HTTP connection) they may be able to encode a 80 valid message in another protocol. The connecting host believes that 81 it is speaking one protocol but the server understands it to be 82 another. The application of Postel's Law exacerbates the issue as 83 many servers will permit gross violations of the expected protocol in 84 order to achieve maximum compatibility with clients. 86 The WebSockets [websockets] protocol seeks to allow low-latency, 87 full-duplex communication between browsers and HTTP servers. 88 However, it also permits an unprecedented amount of attacker control 89 over the contents of the connection. In order to prevent cross- 90 protocol attacks, a mechanism to assure that both client and server 91 are speaking the same protocol is required. To this end, Next 92 Protocol Negotiation extends the TLS [RFC5246] handshake to permit 93 both parties to agree on their intended protocol. 95 2. Requirements Notation 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 3. Next Protocol Negotiation Extension 103 A new extension type ("next_protocol_negotiation(TBD)") is defined 104 and MAY be included by the client in its "ClientHello" message. If, 105 and only if, the server sees this extension in the "ClientHello", it 106 MAY choose to include the extension in its "ServerHello". 108 enum { 109 next_protocol_negotiation(TBD), (65535) 110 } ExtensionType; 112 A new handshake message type ("next_protocol(TBD)") is defined. If, 113 and only if, the server included a "next_protocol_negotiation" 114 extension in its ServerHello message, the client MUST send a 115 "NextProtocol" message after its "ChangeCipherSpec" and before its 116 "Finished" message. 118 struct { 119 opaque selected_protocol<0..255>; 120 opaque padding<0..255>; 121 } NextProtocol; 123 The "extension_data" field of a "next_protocol_negotiation" in a 124 "ClientHello" MUST be empty. 126 The "extension_data" field in a "ServerHello" and the "NextProtocol" 127 message contain opaque bytes to be used by the application layer to 128 negotiate the application layer protocol. The format of this data is 129 not specified in this draft. 131 Unlike many other TLS extensions, this extension does not establish 132 properties of the session, only of the connection. When session 133 resumption or session tickets [RFC5077] are used, the previous 134 contents of this extension are irrelevent and only the values in the 135 new handshake messages are considered. 137 For the same reasons, after a handshake has been performed for a 138 given connection, renegotiations on the same connection MUST NOT 139 include the "next_protocol_negotiation" extension. 141 4. Security considerations 143 The server's list of supported protocols is still advertised in the 144 clear with this extension. This may be undesirable for certain 145 protocols (such as Tor [tor]) where one could imagine that hostile 146 networks would terminate any TLS connection with a server that 147 advertised such a capability. In this case, clients may wish to 148 opportunistically select a protocol that wasn't advertised by the 149 server. However, the workings of such a scheme are outside the scope 150 of this document. 152 5. IANA Considerations 154 This document requires IANA to update its registry of TLS extensions 155 to assign an entry, referred herein as "next_protocol_negotiation". 157 This document also requires IANA to update its registry of TLS 158 handshake types to assign an entry, referred herein as 159 "next_protocol". 161 6. Acknowledgements 163 This document benefitted specifically from discussions with Wan-Teh 164 Chang and Nagendra Modadugu. 166 7. References 168 7.1. Normative References 170 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 171 Requirement Levels", BCP 14, RFC 2119, March 1997. 173 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 174 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 175 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 177 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 178 "Transport Layer Security (TLS) Session Resumption without 179 Server-Side State", RFC 5077, January 2008. 181 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 182 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 184 7.2. Informative References 186 [websockets] 187 Hickson, I., "The Web Socket protocol", Internet Draft 188 (work in progress), October 2009. 190 [tor] Dingledine, R., Matthewson, N., and P. Syverson, "Tor: The 191 Second-Generation Onion Router", August 2004. 193 Appendix A. Changes 195 To be removed by RFC Editor before publication 197 Version 2 renews version 1 without changes. 199 Author's Address 201 Adam Langley 202 Google Inc 204 Email: agl@google.com