search

tQsW / encrypted-ice-candidates

0 stars 0 forks source link

Consider alternatives to the use of the ".encrypted" TLD #12

Open tQsW opened 4 years ago

tQsW commented 4 years ago

Introducing a new global TLD and standardizing its use may be unnecessary for this proposal. Suggestions from the current mmusic discussion include:

  1. A new SDP attribute to signal encrypted candidates, e.g. a=encrypted-candidates.
  2. A sub-domain under ".arpg", e.g. ".encrypted.arpa".
  3. A new field in the candidate-attribute to signal the encrypted candidate type.
tQsW commented 4 years ago

Some thoughts on the option of adding a new SDP attribute.

For non-trickled sessions, the new attribute line becomes part of the session description, and this seems the most probable case for it to work. The JSEP runtime should be able to ignore unknown attributes when processing a description. It then only requires the runtime to support generating an IceCandidate object from the new line to work. If the implementation performs decryption first and transcribes the line to a candidate-attribute, the construction of IceCandidate is unchanged, with the caveat that the decryption happens at the JSEP layer away from the ICE agent. Alternative, the construct-then-decrypt approach requires some change of the parser. Either way, it should not break an existing JSEP implementation.

On the other hand, it does seem to require more changes to work with trickle ICE, when we have the extra constructs in signaling. From a web app perspective, RTCIceCandidate contains the entire candidate-attribute in RTCIceCandidate.candidate. If we replace it with a new attribute line, we still need some placeholders like 0.0.0.0:9 for RTCIceCandidate.ip and port. For the whole thing to work, if we assume the app does not munge RTCIceCandidate, the JSEP in a UA is required to accept a RTCIceCandidate with the candidate, ip and port fields given as above. This may be a break change if a legacy runtime cannot safely ignore it.

tQsW commented 4 years ago

Interop with legacy endpoints is a similar concern for adding a new field to the candidate attribute. Technically, the extension is supported by draft-ietf-mmusic-ice-sip-sdp, to which JSEP delegates for the internal representation of the IceCandidate object. In practice, there exist WebRTC implementations with their own extensions. E.g., the candidate attribute contains the network-cost and network-id fields in Chrome. Interop among browsers and other WebRTC implementations has been working well with these extensions. Though there is a chance that the interop has only converged for these existing fields, the risk of breaking communications with new fields could be relatively low given the attribute is designed to allow extensions.

With new fields, a candidate attribute could be given by

candidate=:1 1 udp 2122262783 0.0.0.0 9 typ host ciphertext 8c9bd03bb7a5a76a5803eebc688f0388fa991acbdf116f6b72fd3a781174cd58

using 0.0.0.0:9 as a placeholder, and the candidate should be discarded if the implementation does not parse the ciphertext field.

juberti commented 4 years ago

Agree that 3) seems like the best option, simple change and probably backward-compatible. We could also use base64 instead of hex for the blob.