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

[Roman Shpount <[e-mail]>]

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 <[e-mail]> wrote:

> On Sun, Nov 3, 2019 at 7:36 PM Martin Thomson <[e-mail]> 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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>> >
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>