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

[Roman Shpount <[e-mail]>]

On Tue, Nov 5, 2019 at 7:13 PM Justin Uberti <[e-mail]> wrote:

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

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

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