idnits 2.17.1 draft-kazuho-protected-sni-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: ---------------------------------------------------------------------------- No issues found here. 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 == Line 140 has weird spacing: '..._shares list ...' == Line 228 has weird spacing: '...er_name the r...' -- The document date (July 19, 2017) is 2473 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) == Unused Reference: 'RFC1035' is defined on line 364, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-21 ** Downref: Normative reference to an Informational RFC: RFC 5869 -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Oku 3 Internet-Draft July 19, 2017 4 Intended status: Standards Track 5 Expires: January 20, 2018 7 TLS Extensions for Protecting SNI 8 draft-kazuho-protected-sni-00 10 Abstract 12 This memo introduces TLS extensions and a DNS Resource Record Type 13 that can be used to protect attackers from obtaining the value of the 14 Server Name Indication extension being transmitted over a Transport 15 Layer Security (TLS) version 1.3 handshake. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 20, 2018. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2 53 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 2 54 3. TLS-Bootstrap DNS Resource Record . . . . . . . . . . . . . . 3 55 4. Changes to ClientHello . . . . . . . . . . . . . . . . . . . 4 56 4.1. Semi-Static Key Share Extension . . . . . . . . . . . . . 5 57 4.2. Encrypted SNI Extension . . . . . . . . . . . . . . . . . 5 58 5. Things to Consider . . . . . . . . . . . . . . . . . . . . . 6 59 5.1. Downgrade Attack Protection . . . . . . . . . . . . . . . 6 60 5.2. Encrypting Other Extensions . . . . . . . . . . . . . . . 6 61 5.3. Mitigating Short-term Performance Impact . . . . . . . . 7 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 8. Acknowledements . . . . . . . . . . . . . . . . . . . . . . . 8 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 9.2. Informative References . . . . . . . . . . . . . . . . . 9 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 As discussed in SNI Encryption in TLS Through Tunneling 73 [I-D.huitema-tls-sni-encryption], it is becoming important to protect 74 from observers the name of the server a client is attempting access. 75 However, Transport Layer Security (TLS) version 1.3 76 [I-D.ietf-tls-tls13] transmits the Server Name Indication extension 77 (([RFC6066], section 3) unencrypted. 79 This memo defines the TLS-Bootstrap DNS Resource Record and two TLS 80 extensions: the Encrypted SNI Extension, the Semi-Static Key Share 81 Extension, that when being used together provides a way to transmit 82 the server name in an encrypted form. 84 1.1. Notational Conventions 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 2. Protocol Overview 92 In the proposed scheme, the server operator publishes its X.509 93 certificate [RFC5280] chain and a semi-static (EC)DH key using the 94 TLS-Bootstrap DNS Record Record. 96 When a client tries to access the server, it queries the DNS resolver 97 for the TLS-Bootstrap DNS Resource Record in addition to the IP 98 address of the server. The two queries can be issued simultaneously. 100 Once the client obtains the address of the server and also the TLS- 101 Bootstrap DNS Resource Record, the client connects to the server and 102 starts a TLS handshake. Instead of sending the Server Name 103 Indication extension, the client will send the server name using the 104 Encrypted SNI Extension, which is encrypted using a symmetric key 105 derived from the result of the (EC)DH key exchange, the two (EC)DH 106 keys being the one embedded in the TLS-Bootstrap DNS Resource Record 107 and the other included in the KeyShare extension of the ClientHello 108 message. 110 3. TLS-Bootstrap DNS Resource Record 112 The DNS Resource Record Type is used to convey the server certificate 113 chain and (EC)DH public keys associated to a hostname. 115 The structure of the record type is: 117 struct { 118 KeyShareEntry key_share; 119 opaque cookie<0..2^16-1>; 120 } SemiStaticKeyShareEntry; 122 struct { 123 CertificateEntry certificate_list<0..2^24-1>; 124 SemiStaticKeyShareEntry semi_static_shares<1..2^16-1>; 125 CipherSuite cipher_suites<2..2^16-2>; 126 SignatureScheme signature_algorithm; 127 opaque signature<0..2^16-1>; 128 } TLSBootstrapRecord; 130 key_share A (EC)DH public key and its type. 132 cookie An identifier associated to the key_share. The value is 133 transmitted from the client to the server during the TLS handshake 134 so that the server can identify which key share as been used. 136 certificate_list The certificate chain of the server certificate 137 along with extensions to verify the validity of the certificate 138 (e.g., OCSP Status extensions ([RFC6066], [RFC6961])). 140 semi_static_shares list of key_shares that the server offers to the 141 client 143 signature The signature is a digital signature using the algorithm 144 specified in the signature_algorithm field. The digital signature 145 covering from the beginning of the structure to the end of the 146 signature_algorithm field. 148 The set of semi-static (EC)DH keys included in the DNS Resource 149 Record MUST be a common value between the server names that are 150 served by the server. For example, if a server hosts three server 151 names: example.com, example.org, example.net, the keys that are 152 published using the DNS Resource Record will be identical for the 153 three server names. 155 4. Changes to ClientHello 157 When a client attempts to connect to a server, it at first queries 158 the DNS resolver to obtain the TLS-Bootstrap DNS Resource Record as 159 well as the IP address of the server. The two DNS queries can be 160 issued simultaneously. 162 Once the client obtains the IP address of the server and also the 163 TLS-Bootstrap DNS Resource Record, it MUST verify the certificate 164 chain and the signature of the TLS-Bootstrap DNS Resource record. 165 After a successful verification, the client will connect to the 166 server and start a TLS 1.3 handshake, by sending a ClientHello 167 handshake message with the following changes. 169 o The "key-share" extension MUST include exactly one KeyShareEntry. 170 The algorithm of the KeyShareEntry MUST be one among the semi- 171 static key shares offered by the server through the TLS-Bootstrap 172 DNS Resource Record. 174 o The "cipher_suite" field MUST include exactly one cipher-suite. 175 It should be one among the cipher-suites offered by the server 176 through the TLS-Bootstrap DNS Resource Record. 178 o The Server Name Indication Extension MUST NOT be used. 180 o The Semi-Static Key Share Extension and the EncryptedSNI Extension 181 MUST be used. 183 A client can use the Cached Information Extension [RFC7924] in hope 184 that the server will try to send the certificates that are identical 185 to the ones that are found in the TLS-Bootstrap DNS Resource Record, 186 and that instead of sending the certificate, the server will use the 187 extension to just send the hash values of the certificate. 189 4.1. Semi-Static Key Share Extension 191 The extension identifies the semi-static (EC)DH key that was being 192 selected by the client. 194 struct { 195 select (Handshake.msg_type) { 196 case client_hello: 197 opaque cookie<0..2^16-1>; 198 case encrypted_extensions: 199 Empty; 200 } 201 } SemiStaticKeyShare; 203 A server MUST abort the handshake with a "unknown-semi-static-key" 204 alert if it find an unknown or an invalid cookie in the extension. A 205 server MUST send an empty Semi-Static Key Share Extension in the 206 EncryptedExtensions handshake message, when the extension appeared in 207 the ClientHello handshake message. 209 4.2. Encrypted SNI Extension 211 The extension contains the Server Name Indication Extension encrypted 212 using a shared key derived from the (EC)DH key exchange. 214 struct { 215 ServerName server_name; 216 opaque padding<0..2^8-1>; 217 } PlaintextEncryptedSNI; 219 struct { 220 select (Handshake.msg_type) { 221 case client_hello: 222 opaque encrypted_payload<0..2^16-1>; 223 case encrypted_extensions: 224 Empty; 225 } 226 } EncryptedSNI; 228 server_name the raw (un-encrypted) value of the Server Name 229 Indication Extension 231 cipher_suite The AEAD algorithm and the hash algorithm to encrypted 232 the encrypted_payload 234 encrypted_payload Contains a PlaintextEncryptedSNI structure 235 encrypted using the only cipher-suite specified by the 236 "cipher_suites" field of the ClientHello message. 238 The key that is being used for protecting the encrypted_payload is 239 calculated as follows by using the HKDF functions [RFC5869], whereas 240 the semi_static_master_key being calculated by applying HKDF-Extract 241 to the result of the (EC)DH key exchange with an empty salt. 243 HKDF-Expand-Label(semi_static_master_key, "encrypted-sni", "", 244 Hash.length) 246 A client MUST pad the PlaintextEncryptedSNI structure so that the 247 length of the server name cannot be observed. 249 A server MUST abort the handshake with a "decode_error" alert if it 250 sees an Encrypted SNI Extension but not the Semi-Static Key Share 251 Extension. A server MUST abort the handshake with a "decrypt_error" 252 alert if it fails to decrypt the encrypted SNI. 254 Once the server successfully decrypts the EncryptedSNI extension, it 255 will use the value of the contained ServerName extension and continue 256 the handshake. 258 A server MUST send an empty EncryptedSNI extension using the 259 EncryptedExtension handshake message to indicate that it has seen the 260 extension in ClientHello. 262 If a client observes an EncryptedExtension handshake message with a 263 Semi-Static Key Share Extension but without a Encrypted SNI extension 264 in response to a ClientHello message containing an Encrypted SNI 265 extension, it MUST abort the handshake by sending a 266 "handshake_failure" alert. 268 5. Things to Consider 270 5.1. Downgrade Attack Protection 272 Attackers might want to block the transmission of a TLS-Bootstrap 273 Record to prevent a server name from being sent in an encrypted form. 274 To mitigate such attacks, we should consider extending HTTP Strict 275 Transport Security [RFC6797] so that the servers can enforce the 276 client the use of the Encrypted SNI extension. 278 5.2. Encrypting Other Extensions 280 We might want to refactor the proposed method to send an arbitrary 281 number of extensions protected within a ClientHello message, rather 282 than just encrypting the Server Name Indication extension. Doing so 283 opens up the possibilty of protected more types of extensions such as 284 the Application-Layer Protocol Negotiation Extension [RFC7301]. Or, 285 it would be possible to use the key to invoke a 0-RTT handshake even 286 when resumption is impossible. 288 5.3. Mitigating Short-term Performance Impact 290 Today, most DNS requests / responses are sent using UDP in cleartext. 291 That fact has two impacts on the proposed method. 293 Firstly, transmitting a TLS-Bootstrap Record will require multiple 294 roundtrips, since the record is unlikely to fit in a single packet. 295 Secondly, the merit of hiding the server name that appears in the 296 ClientHello somewhat diminishes by the fact that the same value might 297 be transmitted unencrypted in the DNS query. 299 Considering the facts, in might make sense to define the transfer of 300 the certificate and the signature as an optional feature, so that the 301 only mandatory field that needs to be conveyed in the TLS-Bootstrap 302 Record will be the (EC)DH public key and the associated cookie. 304 It is likely that such a reduced format will fit into a single UDP 305 packet. Hence the performance degradation will be negligble 306 considering the fact that the query for the TLS-Bootstrap Record can 307 happen simultaneously with the address resolution. 309 The downside of the approach will be that the server name would not 310 be protected from an active attacker. However, until DNS queries 311 start getting transmitted over an encrypted channel, the risk of such 312 attacks might be very low, considering the fact that server names can 313 be found unencrypted in the DNS packets anyways. 315 After DNS over secure transport becomes popular, we can start 316 embedding certificates and digital signatures in the TLS-Bootstrap 317 Record to prevent active attacks, as well as start using the semi- 318 static EC(DH) key for other purposes. 320 6. Security Considerations 322 By using the value of the cookie, servers MUST detect and reject the 323 use of outdated TLS-Bootstrap DNS Resource Records. Otherwise, an 324 attacker might be able to inject an old record to force the peers to 325 agree on using a key-share or a cipher-suite that has turned out to 326 be vulnerable after the record was published on the authoritative 327 server. 329 The injection of malformed or outdated TLS-Bootstrap DNS Resource 330 Record can be used as an attack vector to cause denial-of-service 331 attacks, since misuse of such records by a client ends up in a TLS 332 handshake failure. However, it could be argued that injection of a 333 wrong A record will essentially have the same effect in terms of 334 denial-of-service attacks. In other words, use of a DNS record to 335 transmit TLS handshake parameters does not make us more prone to 336 attacks. 338 7. IANA Considerations 340 The TLS ExtensionType Registry will be updated to contain the 341 codepoints for the Semi-Static Key Share Extension Type and the 342 Encrypted SNI Extension type. 344 The TLS Alert Registry will be updated to contain the "unknown-semi- 345 static-key" alert. 347 The DNS Parameters Registry will be updated to contain the codepoint 348 for the TLS-Bootstrap Resource Record Type. 350 8. Acknowledements 352 Thank you to Subodh Iyengar for suggesting that the certificate chain 353 and the signature could be optional fields of a TLS-Boostrap record. 355 9. References 357 9.1. Normative References 359 [I-D.ietf-tls-tls13] 360 Rescorla, E., "The Transport Layer Security (TLS) Protocol 361 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 362 July 2017. 364 [RFC1035] Mockapetris, P., "Domain names - implementation and 365 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 366 November 1987, . 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, 370 DOI 10.17487/RFC2119, March 1997, 371 . 373 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 374 Housley, R., and W. Polk, "Internet X.509 Public Key 375 Infrastructure Certificate and Certificate Revocation List 376 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 377 . 379 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 380 Key Derivation Function (HKDF)", RFC 5869, 381 DOI 10.17487/RFC5869, May 2010, 382 . 384 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 385 Extensions: Extension Definitions", RFC 6066, 386 DOI 10.17487/RFC6066, January 2011, 387 . 389 9.2. Informative References 391 [I-D.huitema-tls-sni-encryption] 392 Huitema, C. and E. Rescorla, "SNI Encryption in TLS 393 Through Tunneling", draft-huitema-tls-sni-encryption-02 394 (work in progress), July 2017. 396 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 397 Transport Security (HSTS)", RFC 6797, 398 DOI 10.17487/RFC6797, November 2012, 399 . 401 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 402 Multiple Certificate Status Request Extension", RFC 6961, 403 DOI 10.17487/RFC6961, June 2013, 404 . 406 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 407 "Transport Layer Security (TLS) Application-Layer Protocol 408 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 409 July 2014, . 411 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 412 (TLS) Cached Information Extension", RFC 7924, 413 DOI 10.17487/RFC7924, July 2016, 414 . 416 Author's Address 418 Kazuho Oku 420 Email: kazuhooku@gmail.com