[Sipbrandy] Eric Rescorla's No Objection on draft-ietf-sipbrandy-rtpsec-07: (with COMMENT)

Datatracker on behalf of Eric Rescorla <ietf-secretariat-reply@ietf.org> Wed, 06 March 2019 18:47 UTC

Return-Path: <ietf-secretariat-reply@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 02285130D7A; Wed, 6 Mar 2019 10:47:22 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Datatracker on behalf of Eric Rescorla <ietf-secretariat-reply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-sipbrandy-rtpsec@ietf.org, sipbrandy@ietf.org, sipbrandy-chairs@ietf.org, gonzalo.camarillo@ericsson.com, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.93.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155189804196.32647.13609135067257686299.idtracker@ietfa.amsl.com>
Date: Wed, 06 Mar 2019 10:47:21 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipbrandy/X89wwDUG19-1E9B3OBTtdiHYUlU>
Subject: [Sipbrandy] Eric Rescorla's No Objection on draft-ietf-sipbrandy-rtpsec-07: (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, 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,..