Re: [secdir] secdir review of draft-ietf-avtext-sdes-hdr-ext

"Ben Campbell" <ben@nostrum.com> Mon, 18 April 2016 14:29 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F8E12D818; Mon, 18 Apr 2016 07:29:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly11Cm6g0bVG; Mon, 18 Apr 2016 07:29:44 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA9212D68D; Mon, 18 Apr 2016 07:29:44 -0700 (PDT)
Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u3IETdTr008772 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 18 Apr 2016 09:29:39 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10]
From: Ben Campbell <ben@nostrum.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Date: Mon, 18 Apr 2016 09:29:38 -0500
Message-ID: <6A8437B6-9F42-4293-96AC-6FCE3D8DCD91@nostrum.com>
In-Reply-To: <5714A9D6.4010602@ericsson.com>
References: <alpine.BSF.2.20.1604150753390.94067@fledge.watson.org> <5714A9D6.4010602@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/Uh3LJe_prChJmk7ukF-PH_MinPk>
Cc: iesg@ietf.org, draft-ietf-avtext-sdes-hdr-ext.all@ietf.org, "avtext@ietf.org" <avtext@ietf.org>, Samuel Weiler <weiler+ietf@watson.org>, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-avtext-sdes-hdr-ext
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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, 18 Apr 2016 14:29:46 -0000

On 18 Apr 2016, at 4:33, Magnus Westerlund wrote:

> Hi Samuel,
>
> (CC the WG)
>
> Thanks for the review.
>
> Den 2016-04-17 kl. 13:45, skrev Samuel Weiler:
>> 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.
>>
>>
>> I am mostly satisfied with this document's security analysis.  I am
>> worried that implementors will weasel their way around the "SHOULD"s,
>> but the appropriate "SHOULD"s are in the doc.
>>
>> The doc says "...there SHOULD be strong integrity protection and 
>> source
>> authentication of the header extensions" -- I would like to also see
>> specific citation(s).  (e.g. "Use X for integrity protection."  "Use 
>> X
>> for authenticity.")
>
> So I will claim that the common problem that exists with minor RTP 
> extension and RTP payload formats (see RFC 7202) do apply here, we 
> should at least reference RFC 7201 for the options in the security 
> consideration section.
>
> I will edit our source and likely push out such a change quite soon so 
> that it is in place in good time before the IESG call. Unless our AD 
> objects.
>
> I propose to add the below to end of the last paragraph.
>
> "For information regarding options for securing RTP, see [RFC7201]."
>
> And add RFC7201 as an informative reference.

The AD does not object. I think it makes sense to treat this similarly 
to how we treat payload drafts.


>
>>
>> It would be nice to see some discussion of whether these headers
>> increase the utility of RTP as a DOS vector - either by enabling a
>> reflector attack or by triggering heavy computation on a receiving
>> host.  I suspect that there's not much to see here, particularly if
>> there really is integrity protection, but it would be nice to see the
>> analysis.
>
> Yes, this is a reasonable thing to consider. I suggest that we add the 
> below paragraph before the last paragraph in the Security 
> Consideration.
>
> The general RTP header extension mechanism does not itself contain any 
> functionality that is a significant risk for a denial of service 
> attack, nor from processing or storage requirements. This specific 
> extension for SDES items, could potentially be a risk.

Do you mean that _this_ extension might be a risk, or that any specific 
SDES item might be a risk? The sentence sounds like it means the former, 
but the rest of the paragraph suggests the latter.

> If the received SDES item and its content causes the receiver to 
> perform larger amount of processing, create significant storage 
> structures, or emit more network traffic such a risk do exist. The 
> CNAME SDES item is only a minor risk as reception of a CNAME item will 
> create an association between the stream carrying the SDES item and 
> other RTP streams with the same SDES item. As this can result in time 
> synchronizing the media streams some additional processing may result. 
> However, the applications media quality appear will be likely more 
> affected of the wrongly or changing association, than from the impact 
> caused by the additional processing.
>
>
>
>>
[...]