An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)
RFC 8643
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
Alvaro Retana No Objection
Roman Danyliw No Objection
(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/
Éric Vyncke No Objection
I share Mirja's question about the informal status of this document.
(Alexey Melnikov; former steering group member) Yes
(Alissa Cooper; former steering group member) Yes
Please respond to the Gen-ART review. In Section 3, please add a reference for SDP (presumably draft-ietf-mmusic-rfc4566bis).
(Barry Leiba; former steering group member) Yes
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").
(Benjamin Kaduk; former steering group member) No Objection
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.
(Deborah Brungard; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
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.
(Suresh Krishnan; former steering group member) No Objection