Link identity to DTLS transports more tightly

RESOLVED WONTFIX

Status

()

--
enhancement
RESOLVED WONTFIX
5 years ago
4 years ago

People

(Reporter: mt, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
Bug 884573 provides a peerIdentity attribute and the associated baggage for RTCPeerConnection.  That attribute is currently derived globally, based on SDP attributes.  This has a number of drawbacks:

 1. identity can only be tested globally
 2. a=fingerprint attributes must be the same for all m=sections
 3. all m=sections can have only one a=fingerprint attribute
 4. the a=fingerprint attribute must include a fingerprint generated with the same hash function as was in the identity assertion (for us, this is SHA-256)

In theory, a=identity could be a media-section attribute, but because of the above, we can't really implement it.  Even if everything were properly implemented, the API simply doesn't support exposing multiple peerIdentity attributes.  (That might change if the API changes, which is possible, even likely.)

First thing though is to lose items number 3 and number 4.

In order to do this, we should accept multiple a=identity, and check them all.  Each valid assertion will then bear a fingerprint.  We can then pass that through and check that it matches the actual fingerprint that is being used (at this point, we'll have to check that all transports are the same too, see above), and only then set the peerIdentity.  Once we get a hit, we can cancel the IdP and fingerprint checks for any other assertions that are in flight.

This will allow two things:
 - multiple a=fingerprint attributes
 - different hash function used for a=fingerprint and a=identity

The latter is pretty lame, but the former is handy, since we already support that capability and it is used in a number of cases.

A possible twist on this allows for a=identity to fall into media sections, but then enforce an identical name for all sections (as long as we don't have a transport object).  That would be closer to the flexible option and would allow for greater forward compatibility.
(Reporter)

Comment 1

4 years ago
This is mostly OK and will be fixed in bug 996238.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.