idnits 2.17.1 draft-rescorla-tls-partial-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 227. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 204. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 211. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 217. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2006) is 6634 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) -- Looks like a reference, but probably isn't: 'InitialClearBytes' on line 113 ** Downref: Normative reference to an Historic draft: draft-ietf-tls-rfc2246-bis (ref. '2') ** Downref: Normative reference to an Historic draft: draft-rescorla-dtls (ref. '4') Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Rescorla 3 Internet-Draft Network Resonance 4 Expires: August 29, 2006 February 25, 2006 6 Transport Layer Security (TLS) Partial Encryption Mode 7 draft-rescorla-tls-partial-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 29, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document describes an extension to TLS to allow partial 41 encryption of record bodies. This allows the beginning of the record 42 body to be in the clear, thus facilitating debugging and header 43 compression. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3 49 3. Negotiating the Partial Encryption Extension . . . . . . . . . 3 50 4. Record Processing . . . . . . . . . . . . . . . . . . . . . . . 3 51 4.1. Record Transmission . . . . . . . . . . . . . . . . . . . . 4 52 4.2. Record Reception . . . . . . . . . . . . . . . . . . . . . 4 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 55 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 Intellectual Property and Copyright Statements . . . . . . . . . . 7 59 1. Introduction 61 Encryption in Transport Layer Security (TLS) [2] is currently an all- 62 or-nothing proposition. The choices are a cipher suite that has 63 encryption or one of the NULL cipher suites which offer no 64 encryption. This has disadvantages in settings where the application 65 layer itself has some data (such as a header) that it wishes to have 66 in the clear (e.g., for debugging purposes) and some data (such as a 67 payload) that it wishes to have encrypted. This document describes 68 an extension to TLS that allows for the initial portion of the record 69 to remain uncompressed and unencrypted. 71 2. Conventions Used In This Document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [1]. 77 3. Negotiating the Partial Encryption Extension 79 The client requests support for the partial encryption feature by 80 sending the "partial_encryption" extension in its ClientHello. The 81 "extension_data" field contains a PartialEncryption field: 83 struct { 84 uint16 InitialClearBytes; 85 } PartialEncryption 87 The InitialClearBytes value contains the number of bytes which will 88 be in the clear for each application_data record. This value will 89 obtain for the entire life of this association. 91 The server indicates support for the partial encryption feature 92 sending a "partial_encryption" extension with an empty 93 "extension_data" field. This indicates its acceptance of the 94 extension and of the the number of bytes to be sent in the clear. If 95 the server does not support the extension or does not accept the 96 InitialClearBytes value, it MUST ignore the extension. The first 97 application_data record in the new association (after the 98 change_cipher_spec message) MUST use the new encryption mode as 99 described below. 101 4. Record Processing 103 The partial encryption extension only matters for records of type 104 "application_data". All other records should be processed via the 105 usual TLS/DTLS rules. 107 4.1. Record Transmission 109 When the partial encryption extension is in effect, the 110 TLSCiphertext.fragment struct becomes: 112 select (CipherSpec.cipher_type) { 113 opaque plaintext_bytes[InitialClearBytes]; // New field 115 case stream: GenericStreamCipher; 116 case block: GenericBlockCipher; 117 } fragment; 119 The first InitialClearBytes bytes of the TLSPlaintext.fragment are 120 inserted in the TLSCiphertext.plaintext_bytes value. The rest are 121 passed through compression and encryption to form the 122 GenericStreamCipher or GenericBlockCipher values. If the 123 TLSPlaintext.fragment is less than InitialClearBytes then the entire 124 plaintext is left un-encrypted. The same processing applies to DTLS 125 [4]. 127 The TLS MAC remains unchanged and is applied to both the 128 plaintext_bytes and the TLSCompressed.fragment. Where length is 129 computed as InitialClearBytes + TLSCompressed.length. 131 4.2. Record Reception 133 Record reception is relatively simple. The receiver knows whether 134 the partial_plaintext extension is in effect and simply treats the 135 first InitialClearBytes of what would otherwise be the ciphertext as 136 plaintext. After those bytes are removed, the rest of the record can 137 be processed as usual. 139 5. Security Considerations 141 There are two security concerns introduced by these extensions. The 142 first involves the security of the negotiation and the second the 143 security of the transport protocol. Because the negotiation is 144 protected by the TLS/DTLS handshake, attackers can neither force the 145 use of these extensions nor block them while allowing the negotiation 146 to succeed. 148 The second concern is the security if the data. Obviously, no 149 confidentiality is provided for any data in the initial plaintext. 150 However, because the length of the initial plaintext is fixed in the 151 negotiation and the MAC covers the total length, an active attacker 152 cannot convince the receiver to accept values which are encrypted as 153 if they were plaintext or vice versa. 155 One concern that applies solely to DTLS is that an active attacker 156 might manipulate MTU values to attempt to force the sender to split 157 data across multiple records and thus have some application layer 158 data which would otherwise be encrypted sent in the clear. DTLS 159 itself does not do any fragmentation and applications which use this 160 extension MUST NOT fragment the data that they send to DTLS in such a 161 way that sensitive data could be transmitted unencrypted. 163 6. IANA Considerations 165 This document defines an extension to TLS, in accordance with [3]: 167 enum { partial_encryption (??) } ExtensionType; 169 [[ NOTE: These values need to be assigned by IANA ]] 171 7. Normative References 173 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 174 Levels", BCP 14, RFC 2119, March 1997. 176 [2] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", 177 draft-ietf-tls-rfc2246-bis-13 (work in progress), June 2005. 179 [3] Blake-Wilson, S., "Transport Layer Security (TLS) Extensions", 180 draft-ietf-tls-rfc3546bis-02 (work in progress), October 2005. 182 [4] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 183 Security", draft-rescorla-dtls-05 (work in progress), June 2005. 185 Author's Address 187 Eric Rescorla 188 Network Resonance 189 2483 E. Bayshore Rd., #212 190 Palo Alto, CA 94303 191 USA 193 Email: ekr@networkresonance.com 195 Intellectual Property Statement 197 The IETF takes no position regarding the validity or scope of any 198 Intellectual Property Rights or other rights that might be claimed to 199 pertain to the implementation or use of the technology described in 200 this document or the extent to which any license under such rights 201 might or might not be available; nor does it represent that it has 202 made any independent effort to identify any such rights. Information 203 on the procedures with respect to rights in RFC documents can be 204 found in BCP 78 and BCP 79. 206 Copies of IPR disclosures made to the IETF Secretariat and any 207 assurances of licenses to be made available, or the result of an 208 attempt made to obtain a general license or permission for the use of 209 such proprietary rights by implementers or users of this 210 specification can be obtained from the IETF on-line IPR repository at 211 http://www.ietf.org/ipr. 213 The IETF invites any interested party to bring to its attention any 214 copyrights, patents or patent applications, or other proprietary 215 rights that may cover technology that may be required to implement 216 this standard. Please address the information to the IETF at 217 ietf-ipr@ietf.org. 219 Disclaimer of Validity 221 This document and the information contained herein are provided on an 222 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 223 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 224 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 225 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 226 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 227 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 229 Copyright Statement 231 Copyright (C) The Internet Society (2006). This document is subject 232 to the rights, licenses and restrictions contained in BCP 78, and 233 except as set forth therein, the authors retain all their rights. 235 Acknowledgment 237 Funding for the RFC Editor function is currently provided by the 238 Internet Society.