[Sipbrandy] Eric Rescorla's No Objection on draft-ietf-sipbrandy-rtpsec-07: (with COMMENT)
Datatracker on behalf of Eric Rescorla <email@example.com> Wed, 06 March 2019 18:47 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02285130D7A; Wed, 6 Mar 2019 10:47:22 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
From: Datatracker on behalf of Eric Rescorla <firstname.lastname@example.org>
To: "The IESG" <email@example.com>
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, Gonzalo Camarillo <firstname.lastname@example.org>
Date: Wed, 06 Mar 2019 10:47:21 -0800
Subject: [Sipbrandy] Eric Rescorla's No Objection on draft-ietf-sipbrandy-rtpsec-07: (with COMMENT)
List-Id: SIPBRANDY working group discussion list <sipbrandy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipbrandy>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipbrandy>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Mar 2019 18:47:22 -0000
Eric Rescorla has entered the following ballot position for draft-ietf-sipbrandy-rtpsec-07: 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-rtpsec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4970 IMPORTANT S 4.1. > > 4.1. Credentials > > In order to implement the authentication service function in the user > agent, SIP endpoints will need to acquire the credentials needed to > sign for their own identity. That identity is typically carried in How do relying parties determine whether the certificate is attached to an intermediary or the client. S 4.1. > possession certificates similar to those used in the email world > could be offered for SIP, either for greenfield identifiers or for > telephone numbers, this specification does not require their use. > > For users who do not possess such certificates, DTLS-SRTP [RFC5763] > permits the use of self-signed keys. This profile of STIR employs This doesn't seem quite right. DTLS-SRTP uses self-signed certs that go in a fingerprint which is then transitively signed by the cert via STIR COMMENTS S 1. > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 > > 1. Introduction > > The Session Initiation Protocol (SIP) [RFC3261] includes a suite of > security services, ranging from Digest authentication for Nit: maybe "including". Ranging is an odd phrase with three things S 1. > available, such as Secure RTP [RFC3711]. However, the practices > needed to bind security at the media layer to security at the SIP > layer, to provide an assurance that protection is in place all the > way up the stack, rely on a great many external security mechanisms > and practices, and require a central point of documentation to > explain their optimal use as a best practice. This sentence is kind of run-on. S 1. > and practices, and require a central point of documentation to > explain their optimal use as a best practice. > > Revelations about widespread pervasive monitoring of the Internet > have led to a reevaluation of the threat model for Internet > communications [RFC7258]. In order to maximize the use of security I don't actually agree that this is a reevaluation. 3552 already told you what you needed to know here. S 3.1. > STIR generates a signature over certain features of SIP requests, > including header field values that contain an identity for the > originator of the request, such as the From header field or P- > Asserted-Identity field, and also over the media keys in SDP if they > are present. As currently defined, STIR only provides a signature > over the "a=fingerprint" attribute, which is a key fingerprint Not "only" because you just said that it covered other things. Maybe "in additon" S 3.1. > Asserted-Identity field, and also over the media keys in SDP if they > are present. As currently defined, STIR only provides a signature > over the "a=fingerprint" attribute, which is a key fingerprint > utilized by DTLS-SRTP [RFC5763]; consequently, STIR only offers > comprehensive protection for SIP sessions, in concert with SDP and > SRTP, when DTLS-SRTP is the media security service. The underlying I would remove the commas around , in concert,..
- [Sipbrandy] Eric Rescorla's No Objection on draft… Datatracker on behalf of Eric Rescorla