[Standards] Comments on XEP-0320 (DTLS-SRTP)
jonathan at vidyo.com
Tue Dec 20 23:25:34 UTC 2016
Hi — a few comments on XEP-0320 (DTLS-SRTP). (I know the formal Last Call period has closed, but I think these are both pretty serious.)
1. The IETF is working on an update to RFC 4572 (https://tools.ietf.org/html/draft-ietf-mmusic-4572-update-08), the draft that defines certificate fingerprints. One item that this clarifies is that an SDP media description can contain multiple a=fingerprint attributes, both for hash agility and for various cases where multiple different fingerprints might be used.
Unfortunately, the XEP-0320 syntax doesn’t allow multiple fingerprint values. I think this will need to be changed for compatibility with 4572-update (which is what WebRTC will use). (I’d suggest that <fingerprint> could just occur multiple times, but that doesn’t work well with setup being an attribute of <fingerprint>, since a=setup can still only occur once in an SDP media description.)
2. I’m worried that the backward-compatibility behavior of the XEP-0320 syntax is particularly poor. If a non-DTLS Jingle endpoint receives a Jingle session-initiate containing a DTLS fingerprint, it will presumably ignore the elements in the unknown urn:xmpp:jingle:apps:dtls:0 namespace, and interpret the session-initiate as requesting unencrypted media. This seems like a particularly poor failure mode.
I suggest that XEP-0320 be updated to require that you still send an XEP-0167 <encryption> element if you’re using DTLS. This will either include no <crypto> elements if you’re not willing to use explicit keys as a fallback, or can include one or more <crypto> if you are. I’m pretty sure this means that endpoints properly implementing the behavior defined in XEP-0167 (i.e., failing with <security-error> if they don’t see a <crypto> they like) should result in clean fallback or failure for DTLS-SRTP, without requiring pre-call Disco.
More information about the Standards