[secdir] Secdir review of draft-ietf-sipcore-refer-explicit-subscription-02

Vincent Roca <vincent.roca@inria.fr> Mon, 22 June 2015 13:37 UTC

Return-Path: <vincent.roca@inria.fr>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id A47581A8BC5; Mon, 22 Jun 2015 06:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.859
X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id a5cLPrazJG81; Mon, 22 Jun 2015 06:37:39 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8691A8BC0; Mon, 22 Jun 2015 06:37:38 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.13,659,1427752800"; d="asc'?scan'208,217";a="166651881"
Received: from geve.inrialpes.fr ([]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jun 2015 15:37:37 +0200
From: Vincent Roca <vincent.roca@inria.fr>
X-Pgp-Agent: GPGMail 2.5
Content-Type: multipart/signed; boundary="Apple-Mail=_61DF978C-2F24-4292-BF02-C2E9976DA43D"; protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Mon, 22 Jun 2015 15:37:36 +0200
Message-Id: <2E90B73E-0309-4C49-B208-C2E30A0B6B22@inria.fr>
To: IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-sipcore-refer-explicit-subscription@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/BdtrafCXcDRc7I8-DyuEZwbxwR0>
Subject: [secdir] Secdir review of draft-ietf-sipcore-refer-explicit-subscription-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jun 2015 13:37:44 -0000


I have reviewed this document as part of the security directorate’s ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

Summary: almost ready

I have several questions and suggestions WRT the Security Section.

It is said that: « With this update, there may multiple subscribers to any given refer event state."
So what? What are the implications from a security point of view?

IMHO, the third paragraph does not make an appropriate use of the normative vocabulary.
For instance, it is said:
	"the URI should be constructed so that it is not easy to guess, and should be protected against eavesdroppers"
Shouldn’t the author use « SHOULD » on both occasions?
The following sentence is ambiguous. It says:
	"For instance, SIP messages containing this URI SHOULD be sent using TLS or DTLS..."
"SHOULD" and "For instance" are contradictory. I suggest removing "For instance".
Similarly, next sentence says: "can redirect". I think "SHOULD" redirect is more appropriate.
Finally the same remark (i.e. use « SHOULD") can be done for the next two sentences about additional authorization

In the 4th paragraph, it is not clear to me why it is said that there is « a factor of 11 amplification due to retransmissions
of the request ». What are the foundations for this « 11 » factor? And what happens if the victim is SIP aware?

Additionally, I have concerns about backward compatibility.
The mechanisms introduced by this extension may not be backward compatible with RFC 3515 (see section 7).
However I don’t see any discussion in the current document.
There are some guidelines in RFC 6656 (8.3.1) concerning the 202 response code, but what is described in the first
paragraph is new to this document.

Typo, section 8: « be » is missing in the following sentence:
	« With this update, there may multiple subscribers to any given refer event state."