idnits 2.17.1 draft-belyavskiy-fakesni-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 96: '...tted. If present, it MUST match an IP...' RFC 2119 keyword, line 101: '... the Fake SNI RR MUST identify the ori...' RFC 2119 keyword, line 103: '... IP address MUST be different to dis...' RFC 2119 keyword, line 108: '... server MUST return the certificate ...' RFC 2119 keyword, line 109: '...Otherwise server SHOULD abort the conn...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2019) is 1877 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 152 looks like a reference -- Missing reference section? '2' on line 155 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet-Draft TCI 4 Intended status: Experimental March 6, 2019 5 Expires: September 7, 2019 7 Fake Server Name Indication 8 draft-belyavskiy-fakesni-02 10 Abstract 12 The document provides a specification of the Fake Server Name 13 Indication. Being implemented, the Fake SNI specification provides a 14 way to cheat the monitoring solutions without providing any 15 additional information to external observers. 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 https://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 September 7, 2019. 34 Copyright Notice 36 Copyright (c) 2019 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 (https://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 1. Introduction 51 Many DPI solutions use SNI information as a criterion to filter 52 connection to various sites. Though Encrypted SNI makes impossible 53 to read the SNI value, there is information [1] that absence of SNI 54 looks suspicious itself and all communications are blocked. 56 This specification introduces a way to provide a value of SNI treated 57 by TLS server as an alias to one of the names known by server but not 58 matching the possibly suspicious hostname. 60 This specification does not save from DPI solutions but it provides 61 one more loophole to cheat them. 63 2. Fake SNI design goals 65 The solution specified in this document is inspired by the design of 66 Encrypted SNI. It is fully-compatible with current TLS 67 specifications. As it does not make much sense to use it with TLS 68 1.0-1.2, where the original host name will be provided unencrypted in 69 the certificate, in case of TLS 1.3 the certificate is delivered 70 encrypted. 72 The provider publishes a name matching the target name to be provided 73 in the clear text. This document defines a publication mechanism 74 using DNS, but other mechanisms are also possible. 76 When a client wants to establish a TLS connection to a domain served 77 by a Fake SNI-supporting provider, it replaces the value in 78 "server_name" extension in the ClientHello with the value obtained by 79 transport. The provider can then find out the desired name from its 80 configuration and either establish the connection with the desired 81 host or reject it. 83 3. Definitions 85 Original name - the hostname of service that is subject to hide. 87 Fake name - the hostname specified by server and sent by client to 88 indicate intention to connect to host with original name. 90 4. Fake SNI indication 92 Fake SNI information is published in DNS via TXT RR. For example, 93 the Fake SNI record for domain example.com may look like 95 _fakesni.example.com. 60S IN TXT "myfakerecord.com IP" 96 where IP address may be omitted. If present, it MUST match an IP 97 address specified in A/AAAA record for the domain. Specifying IP 98 address for a specific fake name may help in case when a service is 99 hosted using more than one CDN. 101 The fake name specified in the Fake SNI RR MUST identify the original 102 hostname it is valid for. Fake names for different hosts on the same 103 IP address MUST be different to distinguish the original names. 105 5. Server behaviour 107 On receiveing the value of known Fake SNI in the TLS ClientHello 108 server MUST return the certificate matching the original hostname. 109 Otherwise server SHOULD abort the connection. 111 6. Client behaviour 113 Client MAY use the Fake SNI record as fallback if connecting using 114 ESNI is blocked. In this case client initiates normal TLS connection 115 specifying the value from Fake SNI record in the server_name 116 extension. If the certificate received from server does not match 117 the original hostname, the client MUST abort the connection. 118 Otherwise the client MUST follow the normal process of TLS handshake. 120 7. Operational considerations 122 Depending on the DPI modus operandi it may make sense to provide a 123 valid fake name (e.g. from deep-level subdomain) resolving to the 124 same IPs as original hostname does. If DPI tries to resolve the fake 125 name, such behaviour will make distinguishing between real and fake 126 names difficult. 128 8. Security considerations 130 As Fake SNI can be used in TLS 1.2, it does not provide any problems 131 to DPI because in this case the original hostname is available in 132 clear text in server certificate. TLS 1.3 encrypts the Certificate 133 message, so it is RECOMMENDED to use Fake SNI together with TLS 1.3. 134 To strengthen the protection, it's recommended to obtain _fakesni RR 135 via DoT or DoH. 137 As DPI solutions are able to obtain the DNS _fakesni records as 138 legitimate clients do, it is RECOMMENDED to set reasonable TTL values 139 for the _fakesni records. Also it is RECOMMENDED to use such values 140 of fake names that are syntactically correct domain names. Otherwise 141 DPI can recognise the fake names as fake ones. 143 9. Current version of the specification 145 The current version of the specification is available at GitHub 146 repository [2]. 148 10. References 150 10.1. URIs 152 [1] https://mailarchive.ietf.org/arch/msg/tls/ 153 WiT3oEh6PO96mm0z28BNMp0YgGs 155 [2] https://github.com/beldmit/fakesni/ 157 Author's Address 159 Dmitry Belyavskiy 160 Cryptocom LTD 161 Kedrova st, 14/2 162 Moscow 117218 163 RU 165 Email: beldmit@gmail.com