[rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates

[Bernard Aboba <[e-mail]>]

While I understand the overall goal of this document,  it strikes me as
suffering from two major problems:

a. Introduction of backwards compatibility problems and potential
additional delays due to utilization of name resolution mechanisms in ICE,
with a corresponding benefit (successful connectivity checks between host
candidates on the same network) which is only a marginal improvement over
mode 3 (no host candidates).

b. Over-reliance on permission mechanisms which have already been stretched
to the breaking point, leaving the potential for collateral damage in data
channel-only scenarios. Due to limitations in the current permissions
mechanisms, it is not currently practically impossible to distinguish
legitimate data channel applications that would obtain permissions if there
were usable means to do so from illegitimate applications attempting to
compromise user privacy.

Data-channel only scenarios that would be impacted include those where:

1. Permissions cannot be obtained (e.g. where there is no microphone or
camera attached to the device so that getUserMedia will always fail).

2. Low latency communications is a requirement so that TURN server
traversal is unacceptable (e.g. in financial applications where there may
be regulatory requirements relating to allowable delays).

3. TURN traversal would impose an unacceptable financial cost, such as in
branch office scenarios where a TURN servers is not provided in each branch
office, and branch office connectivity may be constrained (still an issue
for branch offices located on other continents).

Essentially, the problem is that these scenarios may have valid reasons why
they cannot utilize or do not wish to utilize getUserMedia as a
permission-granting mechanism.