[Standards] Comments on XEP-0320 (DTLS-SRTP)

Jonathan Lennox 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 mailing list