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

Hi Martin,

Thanks a lot for the feedback. We agree a=encrypted-candidate should be
able to achieve an equivalent result as this initial version or even beyond
encrypting IPs, without modifying the core procedure. We'll edit the draft
accordingly with this suggestion.

On the key management, we think this should be deferred to implementations,
given different options to solve this problem. Chrome enterprise policy is
currently an example for such a solution in managed environments, and it
allows admins to push configuration settings to managed endpoints. For
example, policies like AudioCaptureAllowedUrls
<https://cloud.google.com/docs/chrome-enterprise/policies/?policy=AudioCaptureAllowedUrls>
can
set up a whitelist and DeviceKerborosEncryptionTypes
<https://cloud.google.com/docs/chrome-enterprise/policies/?policy=DeviceKerberosEncryptionTypes>
configures certain ciphersuites.

DHCP could be another example of configuring managed endpoints in addition
to Chrome enterprise policy above. TLS-PSK similarly delegates the
communication of PSK among parties outside the spec space. Given the
diversity of applications even in managed environments, the definition of
the key management feels out of the scope for this document, but this draft
can include example implementations for illustration.

As for errors from key rotation, MAC verification will cause such
candidates to be discarded, and clients will fall back to mDNS, STUN, or
TURN as appropriate. If we feel like that we need to solve this problem
more thoroughly, some implementation guidelines can also be included
regarding maintaining a brief key history and using trial decryption as
needed. We'd appreciate suggestions on further improving these guidelines.

Regards,
Qingsi

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