An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)
Note: This ballot was opened for revision 09 and is now closed.
(Alissa Cooper) Yes
Comment (2019-05-29 for -09)
Please respond to the Gen-ART review. In Section 3, please add a reference for SDP (presumably draft-ietf-mmusic-rfc4566bis).
(Barry Leiba) Yes
Comment (2019-05-28 for -09)
I share the question of why this is Informational and why the shepherd writeup doesn't explain (the writeup says little more than "yes" and "no").
(Alexey Melnikov) Yes
(Deborah Brungard) No Objection
Roman Danyliw No Objection
Comment (2019-05-29 for -09)
(1) Section 1.1. Per “It is only to be used in existing deployments which are attempting to transition to fully secure communications. New applications and new deployments will not use OSRTP.”, I was expecting RFC2119 words for the second sentence on the order of “New application … should not …”. (2) Section 3.1. Is there any value in creating a registry to manage the possible “a=xxx” offer types? (3) Editorial Nits: Section 1.0. Extra space. s/[RFC5939] ./[RFC5939]./ Section 1.0. Expand OSRTP acronym on first use. (done in title and abstract but not in text) Section 3. Typo. s/oportunistic/opportunistic/
Benjamin Kaduk No Objection
Comment (2019-05-29 for -09)
If ZRTP is already an OS method, and there are no changes to the ZRTP usage or security considerations as part of OSRTP, why do we need to cover ZRTP in this document at all (other than a pointer to "this other OS mechanism exists")? I could also see someone subscribing to an "attractive nuisance" theory that obliges us to put a stronger disclaimer against secdes and/or ZRTP usage, since we mention them in this document. Perhaps something about how they are generally considered to not be reasonable solutions for "comprehensive protection" solutions but can still be useful in OS environments? Abstract Opportunistic Secure Real-time Transport Protocol (OSRTP) is an implementation of the Opportunistic Security mechanism, as defined in nit: maybe s/implementation/application/? Section 1 OSRTP allows SRTP to be negotiated with the RTP/AVP profile, with fallback to RTP if SRTP is not supported. nit: Given the preceding context, I don't see a way to read this other than OSRTP using RTP/AVP and disallowing RTP/AVPF. I don't know whether an "RFP/AVP(F)" notation is at all conventional (we do "(D)TLS" and "(EC)DHE" a lot in the security area) or they would need to both be written out. I agree with the directorate reviewer that inlining a substantial portion of the "motivation and requirements for opportunistic secure media" from draft-kaplan-mmusic-best-effort-srtp into this document would be appropriate (while still acknowledging the prior effort). OSRTP requires no additional extensions to SDP or new attributes and is defined independently of the key agreement mechanism used. [...] The "defined independently" part seems to only mostly be true; see, e.g., the security considerations where we override the need for authenticated signaling for DTLS-SRTP OSRTP. Section 2 Please use the boilerplate from RFC 8174 (in particular, just the "BCP 14 [RFC2119] [RFC8174]" label+references is fine). Section 3 nit: I think most recent documents going by use "m=" rather than "m-". It is important to note that OSRTP makes no changes, and has no effect on media sessions in which the offer contains a secure profile nit: comma after "no effect on" -- the current text is saying that OSRTP makes no changes at all, globally, without scoping to media sessions in which the offer contains a secure profile (which I presume to be the intent). I think we also need to add "to" in "makes no changes to". Section 4 While OSRTP does not require authentication of the key-agreement mechanism, it does need to avoid exposing SRTP keys to eavesdroppers, since this could enable passive attacks against SRTP. Section 8.3 of [RFC7435] requires that any messages that contain SRTP keys be As already noted, this is probably supposed to be an RFC 4568 reference. Yet that is specific to secdes and not a generic SRTP consideration. encrypted, and further says that encryption "SHOULD" provide end-to- end confidentiality protection if intermediaries that could inspect the SDP message are present. At the time of this writing, it is understood that the [RFC7435] requirement for end-to-end confidentiality protection is commonly ignored. Therefore, if OSRTP As noted, this is not an RFC 7435 requirement, and 4568 seems to be the most likely interpretation. FWIW, my reading of 4568 is that it requires end-to-end authentication as well as confidentiality. (And yes, we attempt to relax that above.) Finally, the tsvart reviewer's concerns might be alleviated if we say "end-to-end (as opposed to just hop-by-hop) confidentiality protection". Also, it might be nice to give some reference for the "commonly ignored" statement, if such is readily available. is used with SDP Security Descriptions, any such intermediaries (e.g., SIP proxies) must be assumed to have access to the SRTP keys. Given that all of this paragraph (except potentially the first sentence) seems to be secdes-specific, I'd suggest breaking it out into a new paragraph and explicitly scoping to RFC 4568, and possibly even using a subsection to indicate the scope. Also, we should probably have another sentence or two to mention what the potential consequences of intermediate access to keys are. As discussed in [RFC7435], OSRTP is used in cases where support for encryption by the other party is not known in advance, and not required. [...] nit: 7435 does not discuss OS*RTP*'s use at all. So some rewording seems in order, like, "As discussed in [RFC7435], opportunistic security in general, and thus OSRTP specifically, is used" or "Per the discussion in [RFC7435], OSRTP is used", etc. Section 6 There are implementations of [I-D.kaplan-mmusic-best-effort-srtp] in deployed products by Microsoft and Unify. The IMTC "Best Practices for SIP Security" document [IMTC-SIP] recommends this approach. The SIP Forum planned to include support in the SIPconnect 2.0 SIP trunking recommendation [SIPCONNECT]. There are many deployments of ZRTP [RFC6189]. nit: I know this is to be removed before publication, but "recommends this approach" is a bit ambiguous about whether the kaplan approach or this document is being recommended.
(Suresh Krishnan) No Objection
(Mirja Kühlewind) No Objection
Comment (2019-05-22 for -09)
Why is the intended status informational? Unfortunately, this is not further explained in the shepherd write-up. What was the discussion in the group and why was informational decided? As this is a protocol specification, informational does not seem appropriate. Except this is meant to only document an existing deployment but then the document should say so. I think it should rather be experimental.
Alvaro Retana No Objection
Martin Vigoureux No Objection
Éric Vyncke No Objection
Comment (2019-05-27 for -09)
I share Mirja's question about the informal status of this document.