[Sipbrandy] Benjamin Kaduk's No Objection on draft-ietf-sipbrandy-osrtp-09: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 29 May 2019 21:23 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: sipbrandy@ietf.org
Delivered-To: sipbrandy@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E791201D1; Wed, 29 May 2019 14:23:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-sipbrandy-osrtp@ietf.org, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, sipbrandy-chairs@ietf.org, gonzalo.camarillo@ericsson.com, sipbrandy@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.97.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <155916498999.5364.15981943360298533577.idtracker@ietfa.amsl.com>
Date: Wed, 29 May 2019 14:23:09 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipbrandy/E1hGehkRPCFsaVG-hbixvXnqqd8>
Subject: [Sipbrandy] Benjamin Kaduk's No Objection on draft-ietf-sipbrandy-osrtp-09: (with COMMENT)
X-BeenThere: sipbrandy@ietf.org
X-Mailman-Version: 2.1.29
List-Id: SIPBRANDY working group discussion list <sipbrandy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipbrandy>, <mailto:sipbrandy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipbrandy/>
List-Post: <mailto:sipbrandy@ietf.org>
List-Help: <mailto:sipbrandy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipbrandy>, <mailto:sipbrandy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2019 21:23:10 -0000
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.
- [Sipbrandy] Benjamin Kaduk's No Objection on draf… Benjamin Kaduk via Datatracker