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

(I hit send too soon - the rest of the responses are 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?
>
>
> 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.
>
>
> 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?
>
>
starting here - see the previous response for everything above.
>
> 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.
Our AD already noted that the second paragraph should actually be 
removed from this document - it is covered in refer-clarifications.

For the first paragraph - backwards compatibility is ensured by the base 
SIP extension mechanism.
An implementation of 3515 that is not aware of this extension (and the 
update to 3515 established by this document) would reject any requests 
that tried to invoke the extension (if either of the tokens defined here 
appeared in a Require: header field, that implementation would reject 
them with a 420 response.
>
>
> Typo, section 8: « be » is missing in the following sentence:
> « With this update, there may multiple subscribers to any given refer 
> event state."
ack.
>
>
> Cheers,
>
>    Vincent
>
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview