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
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
