Network Working Group E. Kinnear Internet-Draft T. Pauly Intended status: Informational C. Wood Expires: September 12, 2019 Apple Inc. March 11, 2019 TLS Client Network Address Extension draft-kinnear-tls-client-net-address-00 Abstract This document describes a TLS 1.3 extension that can be by clients to request their public network address from a server. This information can be used for a variety of purposes, including: NAT detection, ASN identification, and privacy-driven transport protocol features. 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 September 12, 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. Kinnear, et al. Expires September 12, 2019 [Page 1] Internet-Draft TLS Client Network Address Extension March 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Client Network Address Use Cases . . . . . . . . . . . . . . 2 2.1. Connection Lifetime Optimizations . . . . . . . . . . . . 3 2.2. Privacy Stance Enhancements . . . . . . . . . . . . . . . 3 2.3. Metric Collections . . . . . . . . . . . . . . . . . . . 3 3. Network Address Extension . . . . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Normative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction This document describes a TLS 1.3 [RFC8446] extension that can be by clients to request their public network address from a server. This has several uses, including: NAT detection, ASN identification, and privacy-driven transport protocol features. Servers that support this extension can send the perceived client address to clients. The latter may then confirm whether or not this representation matches their known public address. Unlike the related NAT detection extension for IKE [RFC3947], clients do not send their perceived IP address to servers, even in an obfuscated form. Doing so would introduce an unwanted privacy regression for clients. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Client Network Address Use Cases Knowledge of a public client network address can serve several purposes. This extension allows clients to detect the presence of a NAT or other address-transforming proxy involved in a TLS connection. The following sections descibe several uses for this information. Kinnear, et al. Expires September 12, 2019 [Page 2] Internet-Draft TLS Client Network Address Extension March 2019 2.1. Connection Lifetime Optimizations Middleboxes such as NATs typically have short lifetimes for connection state. Detecting such middleboxes may help influence client connection management logic, such as the use of keep-alive messages. Since NATs often apply to all traffic from an endhost, detection via a TLS connection may assist other non-TLS and non-TCP connections that can be more sensitive to NAT timeouts. 2.2. Privacy Stance Enhancements Address-transforming proxies such as NATs may improve communication privacy by masking the public IP address of clients in a session. Modulo other cleartext signals such as session identifiers, the anonymity set of a connection passing through a NAT is proportional to the number of clients serviced by the NAT. Absent NAT detection, clients cannot determine if their connections are linkable via IP- layer information, such as stable source addresses. As a result, clients cannot determine if privacy-driven policies such as never resuming TLS connections improve privacy. If clients can detect NATs, they can make informed decisions about connection reuse. As a motivating example, consider DNS-over-TLS [RFC7858][RFC8310]. Privacy-sensitive clients may wish to use fresh connections for individual queries so as to not allow recursive resolvers the ability of building client query histories. However, in the absence of a NAT, reusing a connection does not pose a significant privacy regression since such clients are generally identifiable by their IP address. Client network awareness may also influence privacy-driven connection migration policies, such as those prescribed by QUIC [I-D.ietf-quic-transport]. For example, if clients know they are not behind a NAT, then connection ID rotation serves little value in preventing linkability. 2.3. Metric Collections Clients may passively use their public address discovered via TLS to identify their corresponding ASN without the use of explicit probes. 3. Network Address Extension Servers may send the perceived client IP address to its peer using the following "network_address" extension: Kinnear, et al. Expires September 12, 2019 [Page 3] Internet-Draft TLS Client Network Address Extension March 2019 enum { network_address(TBD), (65535) } ExtensionType; When sent by a client, this extension MUST be empty. A server which receives a non-empty network_address extension MUST terminate the connection with an "Illegal Parameter" alert. Supporting servers which receive this extension may respond with a "network_address" extension, shown below, inside the EncryptedExtensions. struct { opaque address<32..255>; } NetworkAddress; address The client's perceived address. In this case, NetworkAddress.address carries the raw network-order byte-wise representation of the client IP address. (Since the extension is encrypted, there is no need to obfuscate the address for transit.) Clients which receive a non-empty NetworkAddress extension may use it to record their public IP address. Clients MUST treat empty NetworkAddress.address extensions as an error and send an Illegal Parameter alert in response. 4. IANA Considerations IANA is requested to Create an entry, network_address(TBD), in the existing registry for ExtensionType (defined in [RFC8446]), with "TLS 1.3" column values being set to "CH, EE", and "Recommended" column being set to "Yes". 5. Security Considerations Since NetworkAddress extension contents are encrypted, this extension introduces no (known) additional security or privacy issues. An earlier design let clients send their address to servers in an obfuscated form, e.g., by hashing the client's perceived IP address with ClientHello.random, so that servers could measure whether or not clients were also behind NATs. However, such obfuscation mechanisms are subject to dictionary attacks and therefore could be used by malicious on-path attackers to learn a client's true public address. Absent this information, there are no explicit signals from a single (non-resumed) TLS connection that such attackers can use to learn the client's public address. Kinnear, et al. Expires September 12, 2019 [Page 4] Internet-Draft TLS Client Network Address Extension March 2019 In general, absent a mechanism to encrypt the client extensions, sending the client's perceived address in any form therefore constitutes a privacy regression. 6. Normative References [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", draft-ietf-quic-transport-18 (work in progress), January 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, DOI 10.17487/RFC3947, January 2005, . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles for DNS over TLS and DNS over DTLS", RFC 8310, DOI 10.17487/RFC8310, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Authors' Addresses Eric Kinnear Apple Inc. One Apple Park Way Cupertino, California 95014 United States of America Email: ekinnear@apple.com Kinnear, et al. Expires September 12, 2019 [Page 5] Internet-Draft TLS Client Network Address Extension March 2019 Tommy Pauly Apple Inc. One Apple Park Way Cupertino, California 95014 United States of America Email: tpauly@apple.com Christopher A. Wood Apple Inc. One Apple Park Way Cupertino, California 95014 United States of America Email: cawood@apple.com Kinnear, et al. Expires September 12, 2019 [Page 6]