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

Justin Uberti <juberti@google.com> Wed, 06 November 2019 00:13 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967BB1200E9 for <rtcweb@ietfa.amsl.com>; Tue, 5 Nov 2019 16:13:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2ALQsDW0e0W for <rtcweb@ietfa.amsl.com>; Tue, 5 Nov 2019 16:13:26 -0800 (PST)
Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEB1C120121 for <rtcweb@ietf.org>; Tue, 5 Nov 2019 16:13:25 -0800 (PST)
Received: by mail-ua1-x930.google.com with SMTP id s25so2400086uap.1 for <rtcweb@ietf.org>; Tue, 05 Nov 2019 16:13:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LbM5kJDq5fvuNv2uOj1LeQkghe2NgwGGHPHqUteFTfg=; b=b8kZhYiPKLLFG6xWAujF5RxWaCMF1lIBdN25En5Zhs3lJqtMaOJZ/VX6WRJTjvlJxH grCYwA+JtYGItz5XzwJAlcogIWswYA7EdnmFvNPytkSqvwGk5tlWMUFvXOntvDztGBqU R+bjt05EmS/rgJXgsBaqTSFcO5Xn7IQChvSMHE0GwLsK6E4k/7MyNZgRFbB/DD1IQ3m2 w/CErzSLorDX07BVlRduoMiQLjmOMq/0zSGcSfOIn2n4N5ywkfIHjeZZj7TfwyE7MM1h tooxTrnwh8VwcklfDl4ubH0xo9cw6DTxl6g1FzGvaJGAeUPo46g2lJEGr/lMWb86g6SY yvAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LbM5kJDq5fvuNv2uOj1LeQkghe2NgwGGHPHqUteFTfg=; b=FqrQkXUgMjxhjnkaBgd5EJv79Ag01a/If8lydnUmqTn2OqP/q/vJ00JnyfWi4lELb/ m+A8D4GSiucGtz2sbYuqfvrLJpqUu2/8pnW50vbe/OXPRmekj6SUq0qQCOdI3re1oV1F WPtIvf1YRJkGJOyNbifJDKLLpsEL2e+EflX/NQ4VnGX3x9jYYjUMOTYCJ08YGEKRpNx5 ozh0OnW8dmNE+kkBbZKtB3W4BBGwMPvhLy80Bguu0PwY+yLDPAKWA7BazM8fCJw/e+Ng c6mfKfp2kRwIGRGsTVCBrwAeL+XV9tLQDVDxexiGAz4rbmphMVSdlwn2dVdp0wqjTeGN JIMw==
X-Gm-Message-State: APjAAAWU54gwJxSP9cP23T+2RcAoK43ji1RqkZK6JjMRWkdqAJBzRE9i qtgtCqPdvBf7/NUN/AwU6EMZnRK+0ZwZqsx16GJ0Xw==
X-Google-Smtp-Source: APXvYqwexfFwqwv8K9r73z8nPd6LcG8LfyKXPeUCA5u3MBdtfGu25JPuhopCdywuKgeFA66KwhW/CxF7zsys8EFyfKo=
X-Received: by 2002:ab0:62a:: with SMTP id f39mr16610171uaf.56.1572999204227; Tue, 05 Nov 2019 16:13:24 -0800 (PST)
MIME-Version: 1.0
References: <CA+m752++Frkcq00Lcg0x6is+cWtg2NNf6unWdEiaG1JwTfNMQw@mail.gmail.com> <df740bf1-304f-4123-8cd0-e0eb1a9dd089@www.fastmail.com> <CA+9kkMAA2Oz4UA7DFjp76JLjdeRk8tOsg7attr_p0Tdz7e0gwA@mail.gmail.com> <CAD5OKxt-yx82U02s5W9kHx+WGdiB3mWjZ1uM2TQTEi2F5K+Psg@mail.gmail.com>
In-Reply-To: <CAD5OKxt-yx82U02s5W9kHx+WGdiB3mWjZ1uM2TQTEi2F5K+Psg@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Tue, 5 Nov 2019 16:13:12 -0800
Message-ID: <CAOJ7v-0J7YSM405hyCfbmez9KTY=h8cNFAdM-i5ccFA-57D0dA@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Cc: Ted Hardie <ted.ietf@gmail.com>, Alex Drake <alexdrake@google.com>, RTCWeb IETF <rtcweb@ietf.org>, Qingsi Wang <qingsi=40google.com@dmarc.ietf.org>, mmusic <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cd4bfa0596a26a0d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/7FbZUDoTSjFYH_ewdpLyIBSVNIo>
Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Nov 2019 00:13:29 -0000

On Tue, Nov 5, 2019 at 1:30 PM Roman Shpount <roman@telurix.com> 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 203.0.113.141 8998 typ host addrtype inipv4
> a=candidate:1 1 UDP 2130706431 foo.bar.com 8998 typ host addrtype dns4
> a=candidate:1 1 UDP 2130706431 foo.bar.com 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.

>
> 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 foo.bar.com
>
> 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.

>
> 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.

>
> 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.


> Best Regards,
> _____________
> Roman Shpount
>
>
> On Tue, Nov 5, 2019 at 2:17 PM Ted Hardie <ted.ietf@gmail.com> wrote:
>
>> On Sun, Nov 3, 2019 at 7:36 PM Martin Thomson <mt@lowentropy.net> wrote:
>>
>>> This draft has the effect of defining a new gTLD.  That's problematic,
>>> and likely unnecessary.  I would encourage you to look into ways to signal
>>> these candidates differently.  a=encrypted-candidate might work, for
>>> instance.  You might be able to encrypt more data than an IP address in the
>>> process.
>>>
>>> I agree with Martin that the use of a  .encrypted pseudo-TLD is not
>> necessary.  If you need a special use name, the IAB has signaled
>> willingness to permit registrations under .arpa.  I don't personally think
>> this is the best approach, but that tree is the right choice if you
>> conclude a special use name is the way to go.
>>
>> regards,
>>
>> Ted
>>
>>
>>
>>
>>> I also don't see how key management works here.  The goal of the draft
>>> is to define a set of entities that you are OK with reading your IP
>>> address, but I don't see any text that addresses the difficulty of a)
>>> identifying the entities in that set, and b) getting those entities the
>>> necessary keys.  Those are the really hard problems in this space.
>>>
>>> I don't see how this provides any sort of algorithm agility or ability
>>> to identify the keys that are in use.  Maybe trial decryption is acceptable
>>> in this context, but that can get unwieldy fairly rapidly.
>>>
>>> On Sat, Nov 2, 2019, at 07:06, Qingsi Wang wrote:
>>> > Greetings.
>>> >
>>> > This draft
>>> > (
>>> https://tools.ietf.org/html/draft-wang-mmusic-encrypted-ice-candidates-00)
>>> proposes a complementary solution to the mDNS candidate detailed in
>>> draft-ietf-rtcweb-mdns-ice-candidates, specifically for managed networks.
>>> IPs of ICE candidates are encrypted via PSK and signaled as pseudo-FQDNs in
>>> this proposal, and it aims to address the connectivity challenge from the
>>> mDNS technique in these managed environments. The current work on this
>>> draft is tracked in https://github.com/tQsW/encrypted-ice-candidates.
>>> >
>>> > Regards,
>>> > Qingsi
>>> > _______________________________________________
>>> > rtcweb mailing list
>>> > rtcweb@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/rtcweb
>>> >
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>