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

From: Qingsi Wang <[email-masked]>
Date: Fri, 1 Nov 2019 13:06:22 -0700

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

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 04 Nov 2019 14:35:51 +1100

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Qingsi Wang <[email-masked]>
Date: Tue, 5 Nov 2019 11:15:18 -0800

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 <[email-masked]> 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.
>
> > (
> 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

---

From: Ted Hardie <[email-masked]>
Date: Tue, 5 Nov 2019 11:17:19 -0800

On Sun, Nov 3, 2019 at 7:36 PM Martin Thomson <[email-masked]> wrote:

> 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

---

From: Roman Shpount <[email-masked]>
Date: Tue, 5 Nov 2019 16:29:39 -0500

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 <[email-masked]> 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
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Justin Uberti <[email-masked]>
Date: Tue, 5 Nov 2019 16:13:12 -0800

On Tue, Nov 5, 2019 at 1:30 PM Roman Shpount <[email-masked]> 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 2122262783 <(212)%20226-2783>
> 1f4712db-ea17-4bcf-a596-105139dfd8bf.local 54596 typ host  addrtype dns6
>

I think this might be useful, but it seems separate from the encryption
proposal, so let's discuss that in its own thread.

> a=candidate:1 1 UDP 2130706431 2122262783 <(212)%20226-2783>

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.

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

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 06 Nov 2019 14:16:00 +1100

On Wed, Nov 6, 2019, at 06:15, Qingsi Wang wrote:
> 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.

If there is an assumption that key provisioning works this way then I can see how you reached this conclusion.  I think that you need to be very careful to describe how that constrains the design in the draft though.  Right now, there is a big hole that screams "key management problems".  I wasn't asking you to define the key management system, just to articulate what properties this design assumes and maybe offer some guidance for implementation.  If this is as simple as you describe, that's great.

I don't think that it is that simple - this is a combination of policy and context that is hard to get right.  If I take that managed device home, why would I hide my address?  Or, why would I share my address with my colleagues?

Finally, you are talking about a secret that many people will know.  For instance, I can easily imagine people posting the Foo company corporate shared key on forums to aid in debugging.

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

For the very constrained configuration you describe, it might be appropriate to rely on trial decryption, but that assumes that all deployments will be able to manage with a very simple scheme.  That's rarely appropriate in the general case.  I'd suggest that some sort of key identifier is probably necessary.

---

From: Sean DuBois <[email-masked]>
Date: Mon, 11 Nov 2019 01:03:56 -0800

Hi,

Really excited to see this RFC. This is a real pain point, and glad it
is being addressed. I implemented this over the weekend and everything
fell into place.

Have you thought about/explored encrypting the entire SessionDescription?
There might be some issues I am not aware of, but it would give us some
other nice things!

* No more SDP munging (or at least make it harder)
   - People shoot themselves in the foot constantly by editing things
   - Will push people to communicate API needs more, instead of more hacks

* Host candidates aren't the only thing you can be fingerprinted off of
  - Agents craft very different SDPs (FireFox vs Chromium)
  - SDPs reveal hardware attributes (Chromium Android has H264 only with HW Accel)
  - Agent may have different experiments/settings (attributes at session/media level)

* Changes to candidate strings is going to cause more breakage
  Maybe this doesn't matter as much, but I anticipate this is going to
  cause more bugs. Some clients/SFUs/MCUs... blew up when mDNS came out,

  I bet another change is going to cause the same thing. It sounds like
  this will be much less likely because people will need to setup
  something up to get the PSK going.
-------

I would love to see example implementations of the Key Management. Is
there any precedent for configuration of the WebRTC agent in managed
networks?

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 11 Nov 2019 11:59:22 +0100

> Have you thought about/explored encrypting the entire SessionDescription?

This would destroy interoperability with any currently fielded
implementation, so it's unlikely to be popular.
It also requires setting up a shared key before you can exchange SDP,
which is a pain (as this draft makes clear).

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Nov 2019 11:28:19 +0000

HI,
    
>       - People shoot themselves in the foot constantly by editing things

People don't modify SDP just because they can - they make it in order to make things work.

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 11 Nov 2019 10:37:25 -0800

Martin said:

"Right now, there is a big hole that screams "key management problems"

[BA] There is an RFC 4107 on Key Management Guidelines:
https://tools.ietf.org/html/rfc4107

Section 2.1 states:

Automated key management MUST be used if any of these conditions hold:

      A party will have to manage n^2 static keys, where n may become
      large.

      Any stream cipher (such as RC4 [TK
<https://tools.ietf.org/html/rfc4107#ref-TK>], AES-CTR [NIST
<https://tools.ietf.org/html/rfc4107#ref-NIST>], or AES-CCM
      [WHF <https://tools.ietf.org/html/rfc4107#ref-WHF>]) is used.

      An initialization vector (IV) might be reused, especially an
      implicit IV.  Note that random or pseudo-random explicit IVs are
      not a problem unless the probability of repetition is high.

      Large amounts of data might need to be encrypted in a short time,
      causing frequent change of the short-term session key.

      Long-term session keys are used by more than two parties.
      Multicast is a necessary exception, but multicast key management
      standards are emerging in order to avoid this in the future.
      Sharing long-term session keys should generally be discouraged.

      The likely operational environment is one where personnel (or
      device) turnover is frequent, causing frequent change of the
      short-term session key.

On Tue, Nov 5, 2019 at 7:16 PM Martin Thomson <[email-masked]> wrote:

> If there is an assumption that key provisioning works this way then I can
> see how you reached this conclusion.  I think that you need to be very
> careful to describe how that constrains the design in the draft though.
> Right now, there is a big hole that screams "key management problems".  I
> wasn't asking you to define the key management system, just to articulate
> what properties this design assumes and maybe offer some guidance for
> implementation.  If this is as simple as you describe, that's great.
>
> I don't think that it is that simple - this is a combination of policy and
> context that is hard to get right.  If I take that managed device home, why
> would I hide my address?  Or, why would I share my address with my
> colleagues?
>
> Finally, you are talking about a secret that many people will know.  For
> instance, I can easily imagine people posting the Foo company corporate
> shared key on forums to aid in debugging.
>
> For the very constrained configuration you describe, it might be
> appropriate to rely on trial decryption, but that assumes that all
> deployments will be able to manage with a very simple scheme.  That's
> rarely appropriate in the general case.  I'd suggest that some sort of key
> identifier is probably necessary.
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 11 Nov 2019 13:58:53 -0500

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

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

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.

>> This way you do not need an additional gTLD and encrypted candidate can
>> be identified using the extra candidate extension.
>>
>

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.

> IV, which ensures the encryption output will be different across

Clear. I missed it on the first read.

> 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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 12 Nov 2019 17:09:57 +0100

> Have you thought about/explored encrypting the entire SessionDescription?

We can already use TLS (HTTPS or WSS) to exchange SDPs (or
"parameters" that the receiver will use to build a "remote SDP"). We
don't need yet another encryption layer to transmit a "blob" /
"string" between endpoints.

>    - People shoot themselves in the foot constantly by editing things

We don't do it for fun.

>    - Will push people to communicate API needs more, instead of more hacks

Breaking the existing ability (even if hacky) to set stereo, inband
FEC, DTX, etc. for OPUS transmission by making it impossible does not
seem a good idea. Yes, a better and real API is needed, but that does
not justify breaking the only way we have to do it nowadays.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Justin Uberti <[email-masked]>
Date: Tue, 12 Nov 2019 11:23:16 -0800

As for precedent for managing Chrome in an enterprise environment,
https://cloud.google.com/docs/chrome-enterprise/policies/ gives a rundown
on what is currently supported, and is the easiest way to do this sort of
thing.

DHCP could also be used, but requires OS support.

---

From: Sean DuBois <[email-masked]>
Date: Tue, 12 Nov 2019 22:39:53 +0000

> which is a pain (as this draft makes clear).
These changes are already going to break interoperability. In a perfect
world you can discard candidates that are invalid, but lots of bad code
is just going to break.

Maybe encrypting the whole SDP isn't the right answer. My concern is
that we are going to revisit this issue again because of the points I
called out, I would like to explore solving the root issue.

---

From: Sean DuBois <[email-masked]>
Date: Tue, 12 Nov 2019 14:52:47 -0800

> People don't modify SDP just because they can - they make it in order to make things work.

Agree, but we are failing developers every time they had to do this.
WebRTC agents should provide standardized APIs so they don't need to
touch the SDP to make things work.

Maybe I am wrong, but when developers using Pion WebRTC do SDP munging I try to
figure out what APIs they need. I have no way to get them into the W3C
though, so far I just have a bucket of 'Proprietary APIs I wish I could
figure out how to upstream.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 12 Nov 2019 23:55:55 +0100

> touch the SDP to make things work.

I do not transmit SDPs in the wire but parameters, and then build the
"remote SDP" locally just to make the PeerConnection API happy. Can we
assume then that "encrypted SDP" makes absolutely no sense? I do agree
that a MUCH better WebRTC API is needed, but "SDP encryption" has zero
relationship with that.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Sean DuBois <[email-masked]>
Date: Tue, 12 Nov 2019 15:08:28 -0800

> that a MUCH better WebRTC API is needed, but "SDP encryption" has zero
That is fine with me, I am not tied to a singular idea!

I just want to accomplish the points in my original email.

---

From: Sean DuBois <[email-masked]>
Date: Tue, 12 Nov 2019 15:07:22 -0800

> "string" between endpoints.
I want to also solve these issues.

* Creating a PeerConnection just so that it can fingerprint the user
* Having to trust the signaling server. It would be nice if I could use
  a 'unsecured' signaling server and not worry about a MITM.

https://saltyrtc.org/pages/why-saltyrtc.html convinced me this matters.

> not justify breaking the only way we have to do it nowadays.
I would love for these APIs to exist. I don't know how to make it happen
though.

I believe the existence of SDP munging is causing these APIs to not
exist. There isn't enough pressure because these things can be
accomplished (and only if you know enough).

Currently The next generation of WebRTC developers is going to have to
re-discover all these hacks. Also since they aren't standardized they
could just go away, and no one is officially 'on the hook' to make sure
they exist.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 13 Nov 2019 12:33:29 -0800

I appreciate the desire to solve a more general problem but I think said
problem is much more difficult than what we are trying to address here -
improving connectivity without sacrificing privacy in a managed network
that doesn't support mDNS.

Because the network is managed, key distribution is much less complicated
than it otherwise would be in the general case. I would suggest we focus on
solving this specific problem and, if successful, we can see if we can take
this solution further.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 13 Nov 2019 15:49:26 -0500

> solving this specific problem and, if successful, we can see if we can take

I agree that since network is managed, solution is much simpler, but we
still might need to deal with some key distribution issues, specifically
procedure for key upgrade within the network. During such upgrade one keys
is typically used for encryption but multiple set of keys can be used to
decrypt the candidate (due to key propagation delay through the network).
One option is to try all available keys and only discard the candidate if
it cannot be decoded using any available key.
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Wed, 13 Nov 2019 13:12:19 -0800

agreed, there is some discussion on this in
https://github.com/tQsW/encrypted-ice-candidates/issues/13.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 14 Nov 2019 10:11:46 +0100

> figure out how to upstream.

Have you tried sending a pointer to the [email-masked] list and
asking if anyone wants to champion them?

(I take it from context that pion is not a W3C member)