Do not allow DNS candidates in "relay" mode

[alvestrand]

This article:
https://www.digitaltrends.com/news/signal-vulnerability-hack-location/
described how to use DNS-valued candidates to get a rough geolocation capability.
This doesn't seem sensible to guard against when normal WebRTC procedures are in use, since the attacker can cause a call setup attempt to servers under his control too, but seems to be relevant when "relay" mode is in use, since that mode was explicitly introduced to avoid revealing the user's IP address-based location.

Suggested fix: Don't use this type of candidate when policy is "relay".

https://w3c.github.io/webrtc-pc/#dom-rtcicetransportpolicy-relay

Add:

"In this mode, remote candidates requiring resolution via some external mechanism, such as FQDN-valued candidates (require DNS lookup) and .local candidates (require MDN lookup), will be discarded."

[fippo]

it seems to me this should be mandated in JSEP, not here?

[alvestrand]

Yep, but the cost of getting changes made to that document at this time is high.

[JonathanLennox]

If there's any way to have DNS done by or through the relay (e.g. DoT/DoH through a proxy, or if the relay type allows connect-by-name) then it's safe to use FQDN-valued candidates so long as the DNS is done that way.

I'm not sure how useful that would be, though.

[rshpount]

How is this different then just issuing an HTTP request to a DNS name which resolves to different IP based on the DNS server used? This is not a new problem. Whatever is used to obfuscate browser location when doing DNS resolution for HTTP requests should also be used for FQDN candidates.

I agree that it does make sense to ignore ".local" candidates when in relay mode.

Another way this specific issue occurs is when DNS name for the relay server is resolved. This can also be location specific. Once again, general DNS resolution obfuscation procedures should apply here.

[fippo]

Another way this specific issue occurs is when DNS name for the relay server is resolved

That is slightly different. The remote candidate is under the attackers control, your own TURN server isn't.

[rshpount]

Another way this specific issue occurs is when DNS name for the relay server is resolved

That is slightly different. The remote candidate is under the attackers control, your own TURN server isn't.

It is not technically your own TURN server -- it is under the web site control, but I see what you are saying.

I guess you can do DNS resolution of non-local FQDN candidates through the TURN server -- it should work as a forwarded UDP socket. This will even work better if geographical locality is actually desired, since your would want them to be resolved to the IP address closest to the TURN server, not the client.

[lgrahl]

Is this identical to the issue discussed in rtcweb-wg/mdns-ice-candidates#121?

Personally, I don't see why non-mDNS should be resolved at all. Is there a use case for that? And for mDNS, we can just discard anything that doesn't follow the mdns-ice-candidates document.

Or, if you prefer code, this would be my proposed patch: threema-ch/webrtc-build-docker#14

This isn't limited to "relay only" mode either. This document could be changed to say "don't resolve DNS unless explicitly allowed by another document with provided constraints". What do you think?

[rshpount]

I agree: Latest ice-sip-sdp says do not resolve FQDN candidates unless their resolution procedures are defined in another document. You can just reference this.

[alvestrand]

An attacker that wishes to verify whether or not you are on the local network can use mDNS candidate resolution to discover this by sniffing mDNS resolution requests (using mDNS candidates that are otherwise completely legitimate); that's the reason for disallowing mDNS resolution in relay mode.

As for turning off DNS candidates entirely until someone writes up a good procedure for them - that makes sense to me. There was a draft for DNS-via-TURN once (https://tools.ietf.org/html/draft-schwartz-tram-turnbyname-00), but that failed to pick up traction. (thanks to @pthatcherg for the link).

[lgrahl]

An attacker that wishes to verify whether or not you are on the local network can use mDNS candidate resolution to discover this by sniffing mDNS resolution requests (using mDNS candidates that are otherwise completely legitimate); that's the reason for disallowing mDNS resolution in relay mode.

Okay, that makes sense in addition to disabling to resolve non-mDNS hostnames. 👍

Edit: Although, if the attacker can sniff traffic on the wire, it's probably still easy to correlate sent packets. But, granted, it takes more effort than just turning on Wireshark as for mDNS.

[lgrahl]

What #2540 hasn't resolved though is this:

I agree: Latest ice-sip-sdp says do not resolve FQDN candidates unless their resolution procedures are defined in another document. You can just reference this.