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. > > > >> [...]
- [secdir] secdir review of draft-ietf-avtext-sdes-… Samuel Weiler
- Re: [secdir] secdir review of draft-ietf-avtext-s… Magnus Westerlund
- Re: [secdir] secdir review of draft-ietf-avtext-s… Samuel Weiler
- Re: [secdir] secdir review of draft-ietf-avtext-s… Ben Campbell
- Re: [secdir] secdir review of draft-ietf-avtext-s… Magnus Westerlund