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

Roman Shpount <roman@telurix.com> Tue, 05 November 2019 21:29 UTC

Return-Path: <roman@telurix.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 07482120BD2 for <rtcweb@ietfa.amsl.com>; Tue, 5 Nov 2019 13:29:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 E9mF8AeQbBp2 for <rtcweb@ietfa.amsl.com>; Tue, 5 Nov 2019 13:29:54 -0800 (PST)
Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 83A12120BC9 for <rtcweb@ietf.org>; Tue, 5 Nov 2019 13:29:54 -0800 (PST)
Received: by mail-pf1-x42a.google.com with SMTP id r4so16910161pfl.7 for <rtcweb@ietf.org>; Tue, 05 Nov 2019 13:29:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cK+SHkfET3DgaSPG9uwbRTrRq/OFnEj0k1wjESgtGj8=; b=vt96niTHS0ImMZ97pk9jebOdJqXd/fEqXS04p43eTgNM6gFXW/92j2LWySgc1iB/6l eneW5B03G2NYhiUkO1AHlMgE0a3yayxt65tZanA78nJ1SvmfiTGfy/ATVpCWZcfllmlc dLRwELDpX6762mTLKpiw6YN9dpnka9L/H6RkAKC+U0DnFSosocxZot7LFGD2SaPfmMP9 iWQw/tRb5SxlS7TDuU9VsrPDtD37IC9gBsuuZuSM+RdZM5+forKmHA/pclBFowZcH5dy X+EQb6t5buoE9roOKeWhEkmwbDKCcrr8r5Xc1wgLR4Z8cCS6HHuAIM/mNN4gZVl4DvuO zb3g==
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=cK+SHkfET3DgaSPG9uwbRTrRq/OFnEj0k1wjESgtGj8=; b=IoeJOUkRBj5T4u4kaZACvQhCJuV8qMeEPsDfEKVk0j6G2qub5s5FDhg5cZJgBwquRz RyMc/pkxew2F98pyEhLI3clWrN0n3xtV4fOt8VR8sBelXRAyr1lN19ZnjZc9cqqoLNFi 1ofXThepkFxRb7qCqyudh2gYWK7aghhdKl9eyNvri1P4F093MIgstWgYqfg7Iral5zW5 kZzHn+MdGf0cAwpz86rG2uHLpkGC8TmNKbPPvhWEwPfMYdBNUyAY33kXx9Buis/iv9pX h1sYFC6Bit1wIHegymuAMdRsOco48sNpe+rA7dP1IBpQgjXrH67t8S7zg3eaOOKaAt9Q cO2A==
X-Gm-Message-State: APjAAAXtH1j5eFN9Y4//K62eA5eWc7xUCVtsMD/p4mIbixnpBr+zWIsR veFsFEpp+ys8xruy0MbvnoGuN3Id3Ec=
X-Google-Smtp-Source: APXvYqwUvp4SwpQKQgYkN74zV+b0oUWYC99pizXcx0MvmminPSuKNLfp8RBVRstjfzBio3j/iuONnA==
X-Received: by 2002:a17:90a:77c7:: with SMTP id e7mr1447018pjs.133.1572989393242; Tue, 05 Nov 2019 13:29:53 -0800 (PST)
Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com. [209.85.210.172]) by smtp.gmail.com with ESMTPSA id s8sm6870534pgi.54.2019.11.05.13.29.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Nov 2019 13:29:51 -0800 (PST)
Received: by mail-pf1-f172.google.com with SMTP id d13so16931980pfq.2; Tue, 05 Nov 2019 13:29:50 -0800 (PST)
X-Received: by 2002:a62:8705:: with SMTP id i5mr210346pfe.238.1572989390560; Tue, 05 Nov 2019 13:29:50 -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>
In-Reply-To: <CA+9kkMAA2Oz4UA7DFjp76JLjdeRk8tOsg7attr_p0Tdz7e0gwA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 5 Nov 2019 16:29:39 -0500
X-Gmail-Original-Message-ID: <CAD5OKxt-yx82U02s5W9kHx+WGdiB3mWjZ1uM2TQTEi2F5K+Psg@mail.gmail.com>
Message-ID: <CAD5OKxt-yx82U02s5W9kHx+WGdiB3mWjZ1uM2TQTEi2F5K+Psg@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
Cc: Martin Thomson <mt@lowentropy.net>, 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="000000000000dc228c0596a02114"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/3x_onl33X-uYngzAT50_LYpGKNo>
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: Tue, 05 Nov 2019 21:29:57 -0000

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

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

Furthermore, local addresses before encryption should be prefixed with some
random nonce so that encrypted local addresses cannot be used for
fingerprinting.

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.

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
>