[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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,
              <https://www.rfc-editor.org/info/rfc3947>.

   [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, <https://www.rfc-editor.org/info/rfc7858>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [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,
              <https://www.rfc-editor.org/info/rfc8310>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/