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

[Justin Uberti <[e-mail]>]

On Tue, Nov 5, 2019 at 1:30 PM Roman Shpount <[e-mail]> 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 <[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
>>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>