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

Philipp Hancke fippo at goodadvice.pages.de
Mon Dec 26 11:03:20 UTC 2016


Am 21.12.2016 um 00:25 schrieb Jonathan Lennox:
> 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.)

Thanks for raising them! Also for pointing out that this has been in 
"proposed" state for way too long... :-/

> 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.

ah... the restrictions of 4572 have been particularly annoying.
Lance and me were using the "allow multiple fingerprints" approach in 
sdp-jingle-json 
(https://github.com/otalk/sdp-jingle-json/blob/master/lib/tojson.js#L186)

> 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.)

We pluck the first setup attribute.

> 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.

The initiator should use disco or caps to determine support before 
sending an offer (i'd note that this is a rather theoretical PoV).
And hopefully the initiator will send a session-terminate with a 
security-error when it receives a non-crypto answer.

> 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.

I don't think we can use <encryption required=1/> since 
http://xmpp.org/extensions/xep-0167.html#srtp has a MUST requiring at 
least one crypto.
Which means that this approach might break more stuff. Or we're lucky 
and as you suggest "i dont like this crypto" also applies to violating 
that MUST.

> Thoughts?

+1 on making it clear that there can be multiple fingerprints.

cheers

Philipp


More information about the Standards mailing list