idnits 2.17.1 draft-kinnear-tls-client-net-address-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 -- The document date (March 11, 2019) is 1873 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-18 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Kinnear 3 Internet-Draft T. Pauly 4 Intended status: Informational C. Wood 5 Expires: September 12, 2019 Apple Inc. 6 March 11, 2019 8 TLS Client Network Address Extension 9 draft-kinnear-tls-client-net-address-00 11 Abstract 13 This document describes a TLS 1.3 extension that can be by clients to 14 request their public network address from a server. This information 15 can be used for a variety of purposes, including: NAT detection, ASN 16 identification, and privacy-driven transport protocol features. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 12, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 54 2. Client Network Address Use Cases . . . . . . . . . . . . . . 2 55 2.1. Connection Lifetime Optimizations . . . . . . . . . . . . 3 56 2.2. Privacy Stance Enhancements . . . . . . . . . . . . . . . 3 57 2.3. Metric Collections . . . . . . . . . . . . . . . . . . . 3 58 3. Network Address Extension . . . . . . . . . . . . . . . . . . 3 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 6. Normative References . . . . . . . . . . . . . . . . . . . . 5 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 This document describes a TLS 1.3 [RFC8446] extension that can be by 67 clients to request their public network address from a server. This 68 has several uses, including: NAT detection, ASN identification, and 69 privacy-driven transport protocol features. Servers that support 70 this extension can send the perceived client address to clients. The 71 latter may then confirm whether or not this representation matches 72 their known public address. 74 Unlike the related NAT detection extension for IKE [RFC3947], clients 75 do not send their perceived IP address to servers, even in an 76 obfuscated form. Doing so would introduce an unwanted privacy 77 regression for clients. 79 1.1. Requirements Language 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 83 "OPTIONAL" in this document are to be interpreted as described in 84 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 85 as shown here. 87 2. Client Network Address Use Cases 89 Knowledge of a public client network address can serve several 90 purposes. This extension allows clients to detect the presence of a 91 NAT or other address-transforming proxy involved in a TLS connection. 92 The following sections descibe several uses for this information. 94 2.1. Connection Lifetime Optimizations 96 Middleboxes such as NATs typically have short lifetimes for 97 connection state. Detecting such middleboxes may help influence 98 client connection management logic, such as the use of keep-alive 99 messages. 101 Since NATs often apply to all traffic from an endhost, detection via 102 a TLS connection may assist other non-TLS and non-TCP connections 103 that can be more sensitive to NAT timeouts. 105 2.2. Privacy Stance Enhancements 107 Address-transforming proxies such as NATs may improve communication 108 privacy by masking the public IP address of clients in a session. 109 Modulo other cleartext signals such as session identifiers, the 110 anonymity set of a connection passing through a NAT is proportional 111 to the number of clients serviced by the NAT. Absent NAT detection, 112 clients cannot determine if their connections are linkable via IP- 113 layer information, such as stable source addresses. As a result, 114 clients cannot determine if privacy-driven policies such as never 115 resuming TLS connections improve privacy. 117 If clients can detect NATs, they can make informed decisions about 118 connection reuse. As a motivating example, consider DNS-over-TLS 119 [RFC7858][RFC8310]. Privacy-sensitive clients may wish to use fresh 120 connections for individual queries so as to not allow recursive 121 resolvers the ability of building client query histories. However, 122 in the absence of a NAT, reusing a connection does not pose a 123 significant privacy regression since such clients are generally 124 identifiable by their IP address. 126 Client network awareness may also influence privacy-driven connection 127 migration policies, such as those prescribed by QUIC 128 [I-D.ietf-quic-transport]. For example, if clients know they are not 129 behind a NAT, then connection ID rotation serves little value in 130 preventing linkability. 132 2.3. Metric Collections 134 Clients may passively use their public address discovered via TLS to 135 identify their corresponding ASN without the use of explicit probes. 137 3. Network Address Extension 139 Servers may send the perceived client IP address to its peer using 140 the following "network_address" extension: 142 enum { 143 network_address(TBD), (65535) 144 } ExtensionType; 146 When sent by a client, this extension MUST be empty. A server which 147 receives a non-empty network_address extension MUST terminate the 148 connection with an "Illegal Parameter" alert. 150 Supporting servers which receive this extension may respond with a 151 "network_address" extension, shown below, inside the 152 EncryptedExtensions. 154 struct { 155 opaque address<32..255>; 156 } NetworkAddress; 158 address The client's perceived address. 160 In this case, NetworkAddress.address carries the raw network-order 161 byte-wise representation of the client IP address. (Since the 162 extension is encrypted, there is no need to obfuscate the address for 163 transit.) Clients which receive a non-empty NetworkAddress extension 164 may use it to record their public IP address. Clients MUST treat 165 empty NetworkAddress.address extensions as an error and send an 166 Illegal Parameter alert in response. 168 4. IANA Considerations 170 IANA is requested to Create an entry, network_address(TBD), in the 171 existing registry for ExtensionType (defined in [RFC8446]), with "TLS 172 1.3" column values being set to "CH, EE", and "Recommended" column 173 being set to "Yes". 175 5. Security Considerations 177 Since NetworkAddress extension contents are encrypted, this extension 178 introduces no (known) additional security or privacy issues. 180 An earlier design let clients send their address to servers in an 181 obfuscated form, e.g., by hashing the client's perceived IP address 182 with ClientHello.random, so that servers could measure whether or not 183 clients were also behind NATs. However, such obfuscation mechanisms 184 are subject to dictionary attacks and therefore could be used by 185 malicious on-path attackers to learn a client's true public address. 186 Absent this information, there are no explicit signals from a single 187 (non-resumed) TLS connection that such attackers can use to learn the 188 client's public address. 190 In general, absent a mechanism to encrypt the client extensions, 191 sending the client's perceived address in any form therefore 192 constitutes a privacy regression. 194 6. Normative References 196 [I-D.ietf-quic-transport] 197 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 198 and Secure Transport", draft-ietf-quic-transport-18 (work 199 in progress), January 2019. 201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 202 Requirement Levels", BCP 14, RFC 2119, 203 DOI 10.17487/RFC2119, March 1997, 204 . 206 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 207 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 208 DOI 10.17487/RFC3947, January 2005, 209 . 211 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 212 and P. Hoffman, "Specification for DNS over Transport 213 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 214 2016, . 216 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 217 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 218 May 2017, . 220 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 221 for DNS over TLS and DNS over DTLS", RFC 8310, 222 DOI 10.17487/RFC8310, March 2018, 223 . 225 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 226 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 227 . 229 Authors' Addresses 231 Eric Kinnear 232 Apple Inc. 233 One Apple Park Way 234 Cupertino, California 95014 235 United States of America 237 Email: ekinnear@apple.com 238 Tommy Pauly 239 Apple Inc. 240 One Apple Park Way 241 Cupertino, California 95014 242 United States of America 244 Email: tpauly@apple.com 246 Christopher A. Wood 247 Apple Inc. 248 One Apple Park Way 249 Cupertino, California 95014 250 United States of America 252 Email: cawood@apple.com