Network Working Group Internet-Draft TCI Intended status: Experimental February 19, 2019 Expires: August 23, 2019 Fake Server Name Indication draft-belyavskiy-fakesni-00 Abstract The document provides a specification of the Fake Server Name Indication. Being implemented, the Fake SNI specification provides a way to work around the monitoring solutions without providing any additional information to external observers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 23, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Expires August 23, 2019 [Page 1] Internet-Draft Fake Server Name Indication February 2019 1. Introduction Many DPI solutions use SNI information as a criterion to filter connection to various sites. Though Encrypted SNI makes impossible to read the SNI value, there is information [1] that absence of SNI looks suspicious itself and all communications are blocked. This specification introduces a way to provide a value of SNI treated by TLS server as an alias to one of the names known by server but not matching the possibly suspicious hostname. 2. Fake SNI design goals The solution specified in this document is inspired by the design of Encrypted SNI. The provider publishes a name matching the target name to be provided in the clear text. This document defines a publication mechanism using DNS, but other mechanisms are also possible. When a client wants to establish a TLS connection to a domain served by a Fake SNI-supporting provider, it replaces the value in "server_name" extension in the ClientHello with the value obtained by transport. The provider can then find out the desired name from its configuration and either establish the connection with the desired host or reject it. 3. Fake SNI indication Fake SNI information is published in DNS via TXT RR. For example, the Fake SNI record for domain example.com may look like _fakesni.example.com. 60S IN TXT "myfakerecord.com IP" where IP address may be omitted. If present, it MUST match an IP address specified in A/AAAA record for the domain. Value specified in the Fake SNI RR MUST NOT match any hostname available for the IP address it is valid for. 4. Server behaviour On receiveing the value of known Fake SNI in the TLS ClientHello server MUST return the certificate matching the original hostname. Otherwise server SHOULD abort the connection. Expires August 23, 2019 [Page 2] Internet-Draft Fake Server Name Indication February 2019 5. Client behaviour Client MAY use the Fake SNI record as fallback if connecting using ESNI is blocked. In this case client initiates normal TLS connection specifying the value from Fake SNI record in the server_name extension. If the certificate received from server does not match the original hostname, the client MUST abort the connection. Otherwise the client MUST follow the normal process of TLS handshake. 6. Security considerations TBD 7. References 7.1. URIs [1] https://mailarchive.ietf.org/arch/msg/tls/ WiT3oEh6PO96mm0z28BNMp0YgGs Author's Address Dmitry Belyavskiy Cryptocom LTD Kedrova st, 14/2 Moscow 127083 RU Email: beldmit@gmail.com Expires August 23, 2019 [Page 3]