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

Robert Sparks <> Mon, 22 June 2015 15:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EA1EB1A87A6; Mon, 22 Jun 2015 08:34:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.01
X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3Zs-6ZH3LITg; Mon, 22 Jun 2015 08:34:54 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E3B181A802A; Mon, 22 Jun 2015 08:34:53 -0700 (PDT)
Received: from unnumerable.local ( []) (authenticated bits=0) by (8.15.1/8.14.9) with ESMTPSA id t5MFYq9l034472 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 22 Jun 2015 10:34:53 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be unnumerable.local
Message-ID: <>
Date: Mon, 22 Jun 2015 10:34:47 -0500
From: Robert Sparks <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Vincent Roca <>, IESG <>,,
References: <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------030002040501090805070208"
Archived-At: <>
Subject: Re: [secdir] Secdir review of draft-ietf-sipcore-refer-explicit-subscription-02
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Jun 2015 15:34:57 -0000

Thanks Vincent -

Responses inline:

On 6/22/15 8:37 AM, Vincent Roca wrote:
> Hello,
> 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?
Hmm. I wonder if sentence order made this less clear than it should have 

The paragraph that sentence appears in discusses exactly what the 
implications are - specifically that there is a new authorization 
The paragraph that follow talks about how we deal with having that new 

> 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
> mechanisms.
Ben made a similar comment. The first 2119 requirement you point to 
needs to move up into the protocol definition part of the document.
The second is restating text that's in RFC3261, and we don't need to 
repeat the 2119 here - I'll clarify the language to say "use the 
mechanisms the base specification provides".

> 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?
This is base SIP behavior. The non-INVITE transaction state machine 
retransmits 11 times before giving up if something on the other end 
doesn't talk back
(which is what will happen if the other endpoint is not SIP aware).
> And what happens if the victim is SIP aware?
It will send an appropriate response, so there won't be the 
retransmissions of the request. In other words, sending this as raw 
traffic towards a sip aware element is no different than sending any 
other sip request towards a sip aware element.
> 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."
> Cheers,
>    Vincent