Using Multicast DNS to protect privacy when exposing ICE candidates
draft-ietf-rtcweb-mdns-ice-candidates-02

Document Type Active Internet-Draft (rtcweb WG)
Last updated 2018-10-22
Replaces draft-mdns-ice-candidates
Stream IETF
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
RTCWEB                                                         Y. Fablet
Internet-Draft                                                Apple Inc.
Intended status: Informational                               J. de Borst
Expires: April 25, 2019                                        J. Uberti
                                                                 Q. Wang
                                                                  Google
                                                        October 22, 2018

  Using Multicast DNS to protect privacy when exposing ICE candidates
                draft-ietf-rtcweb-mdns-ice-candidates-02

Abstract

   WebRTC applications collect ICE candidates as part of the process of
   creating peer-to-peer connections.  To maximize the probability of a
   direct peer-to-peer connection, client private IP addresses are
   included in this candidate collection.  However, disclosure of these
   addresses has privacy implications.  This document describes a way to
   share local IP addresses with other clients while preserving client
   privacy.  This is achieved by obfuscating IP addresses with
   dynamically generated Multicast DNS (mDNS) [RFC6762] names.

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 April 25, 2019.

Copyright Notice

   Copyright (c) 2018 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

Fablet, et al.           Expires April 25, 2019                 [Page 1]
Internet-Draft             mdns-ice-candidates              October 2018

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Principle . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  ICE Candidate Gathering . . . . . . . . . . . . . . . . .   3
     3.2.  ICE Candidate Processing  . . . . . . . . . . . . . . . .   4
   4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   6
     5.1.  Statistics  . . . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Interactions With TURN Servers  . . . . . . . . . . . . .   6
     5.3.  Generated Names Reuse . . . . . . . . . . . . . . . . . .   7
     5.4.  Specific Browsing Contexts  . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     6.1.  mDNS Message Flooding . . . . . . . . . . . . . . . . . .   7
     6.2.  Malicious Responses to Deny Name Registration . . . . . .   8
     6.3.  Monitoring of Sessions  . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Specification Requirements  . . . . . . . . . . . . . . . . .   9
   9.  Informative References  . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   As detailed in [IPHandling], exposing client private IP addresses by
   default maximizes the probability of successfully creating direct
   peer-to-peer connection between two clients, but creates a
   significant surface for user fingerprinting.  [IPHandling] recognizes
   this issue, but also admits that there is no current solution to this
   problem; implementations that choose to use Mode 3 to address the
   privacy concerns often suffer from failing or suboptimal connections
   in WebRTC applications.  This is particularly an issue on unmanaged
   networks, typically homes or small offices, where NAT loopback may
   not be supported.

   This document proposes an overall solution to this problem by
   registering ephemeral mDNS names for each local private IP address,
   and then providing those names, rather than the IP addresses, to the
Show full document text