[Sipbrandy] Benjamin Kaduk's No Objection on draft-ietf-sipbrandy-osrtp-09: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-sipbrandy-osrtp-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-osrtp/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.