Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates

Roman Shpount <> Mon, 11 November 2019 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B9B2B1208ED for <>; Mon, 11 Nov 2019 10:59:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oKyimyOhQr6M for <>; Mon, 11 Nov 2019 10:59:07 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 42FAF1209DF for <>; Mon, 11 Nov 2019 10:59:07 -0800 (PST)
Received: by with SMTP id ay6so8181766plb.0 for <>; Mon, 11 Nov 2019 10:59:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lFmw6ipAwL19dSPjd2i8sxGVBkVKLipvEfnPEbKr8jg=; b=Vanmz+DPgjMQKQLnoKQauJfjtLDy2gBeGwrUa4dmYN82LF2iodsMeKp8oJxJ/ySzOM wHhaoTI9HWjRt11d+kIMHzmuc84jrCHFgDigEDGYBwvlUwChYjz0jHns0BkIdJQytVQG /eHHqGx9kC1SMHmp+MEj/3V83rQR3eOIlwTngKakgK/XeqgZ8IAqi8ba1rmTcXpYEr4z NYwGTMvQrvIB1cLaD6a/kbipU0PBBuLQxlqhEHJwYRyrxmoC7fWhBytcQJUaRMd97KPC ttfQTYZl6zwds6v9pVQw2YTZwMqsLRqKEjeWDrkeiC7EEC+too6n82wNCVXVnqRZHgMC rzLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lFmw6ipAwL19dSPjd2i8sxGVBkVKLipvEfnPEbKr8jg=; b=JAkenNpCaaKbTDATYC7Gg8aFpE1DbQko4DeehwGKolVrmp+2Rlk7bpn/ZJGFwBBAn1 RWZVTSEiaLu3Gt8UbXWWVUYMrJD7wiIO6MALGx5v5tsxf2MPiOGaZlWw0S80e8Leelfm +vsj/4Tj1ndL1J5l67XkSXiAswF/05ZduJNkZg8u0v73ReSFfHypoDlZWXOUL4k6z447 uYTrWqRsxCZz0Lie0zx0RKLz6k9JtRXV3mShdTmXY56FAQZS1NVqK97Oux52wKwgC49B DWjSHNA4Exn/PjLDq9f3fHRwlhaIRtyD0BxyIJXLtNR2vSr8NacWnBp2YQW4vF3HNazr OsVw==
X-Gm-Message-State: APjAAAWCmOrUxeh7GiQ42iqwU9Ndf7xFujcfBLvdYTM9qI4A6nw3kyZw J405qiVU12jfooaECU4ei3jhhtTeO4U=
X-Google-Smtp-Source: APXvYqwbOGx/KET1xhmnX3BKyCyvq0jzS/Y0ZYKt9rJGnNfp93q68VtLggAA25Q7kKQdf9/Q88yRfg==
X-Received: by 2002:a17:902:8f94:: with SMTP id z20mr27278661plo.21.1573498746223; Mon, 11 Nov 2019 10:59:06 -0800 (PST)
Received: from ( []) by with ESMTPSA id m65sm572782pje.3.2019. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Nov 2019 10:59:05 -0800 (PST)
Received: by with SMTP id 193so11236539pfc.13; Mon, 11 Nov 2019 10:59:04 -0800 (PST)
X-Received: by 2002:a17:90b:110f:: with SMTP id gi15mr690084pjb.128.1573498744529; Mon, 11 Nov 2019 10:59:04 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Roman Shpount <>
Date: Mon, 11 Nov 2019 13:58:53 -0500
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Justin Uberti <>
Cc: Ted Hardie <>, Alex Drake <>, RTCWeb IETF <>, Qingsi Wang <>, mmusic <>
Content-Type: multipart/alternative; boundary="000000000000b8eccd059716b948"
Archived-At: <>
Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Nov 2019 18:59:10 -0000

On Tue, Nov 5, 2019 at 7:13 PM Justin Uberti <> wrote:

> On Tue, Nov 5, 2019 at 1:30 PM Roman Shpount <> wrote:
>> One thing that I thought would make all DNS in ICE candidate work better
>> is some sort of "addrtype" candidate extension.
>> It would work like:
>> a=candidate:1 1 UDP 2130706431 8998 typ host addrtype inipv4
>> a=candidate:1 1 UDP 2130706431 8998 typ host addrtype dns4
>> a=candidate:1 1 UDP 2130706431 8998 typ host addrtype dns6
>> a=candidate:1 1 udp 2122262783 <(212)%20226-2783>
>> 1f4712db-ea17-4bcf-a596-105139dfd8bf.local 54596 typ host  addrtype dns6
>> This way client would know which DNS request (A or AAAA) should be used
>> to resolve the DNS name in the candidate. c= and m= line can also be
>> generated unambiguously if address type is specified in the candidate and
>> is not determined during resolution time.
> I think this might be useful, but it seems separate from the encryption
> proposal, so let's discuss that in its own thread.

We will need to update ice-sip-sdp to allow DNS (including mdns and
encrypted candidates). I think adding addrtype should address most of the
issues with the existing DNS ice-candidates. We just need to make sure that
people who care about DNS in ice candidate review it.

 For encrypted candidate, distribution of the actual encryption key can be
>> implementation specific, but there should be some way to identify which key
>> is used to encrypt the candidates. This will likely require additional
>> candidate extension, such as "keyid":
>> a=candidate:1 1 UDP 2130706431 2122262783 <(212)%20226-2783>
>> 8c9bd03bb7a5a76a5803eebc688f0388.fa991acbdf116f6b72fd3a781174cd58.local 8998
>> typ host addrtype dnsipv6 keyid
>> This way you do not need an additional gTLD and encrypted candidate can
>> be identified using the extra candidate extension.
> Not sure we need a keyid, but marking the encrypted candidate type somehow
> in the candidate-attribute seems like a good thing to consider.

What I am concerned about are graceful key updates in the enterprise. This
might require several keys to be operational at the same time with one key
used for encryption and multiple keys used to de-crypt.

Furthermore, local addresses before encryption should be prefixed with some
>> random nonce so that encrypted local addresses cannot be used for
>> fingerprinting.
> This is already described in the draft - the ice-pwd value is used for the
> IV, which ensures the encryption output will be different across
> PeerConnections.

Clear. I missed it on the first read.

Finally, probably in W3C we need to discuss if any API updates are required
>> to enable encryption in ICE candidates. I think an additional option to
>> createOffer/createAnswer that specifies which key to use for candidate
>> encryption would probably be the best solution. Distributing actual keys
>> can then be done via enterprise policies or keys can be pre-provisioned
>> with web browsers via some sort of enrollment mechanism.
>> Can you explain more as to why? We don't want app developers to have to
> care about this, or else this solution will never get off the ground.

I guess we can get away without the API and keep key management completely
outside of JavaScript.
Roman Shpount