Re: [secdir] Security review of draft-ietf-avtext-rid-04
Adam Roach <adam@nostrum.com> Thu, 06 October 2016 19:27 UTC
Return-Path: <adam@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 1DCC5129416; Thu, 6 Oct 2016 12:27:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.895
X-Spam-Level:
X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.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 MbONwb1Eub_1; Thu, 6 Oct 2016 12:27:07 -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 2201012940F; Thu, 6 Oct 2016 12:27:07 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u96JR4Vu086653 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 6 Oct 2016 14:27:06 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
To: Hilarie Orman <hilarie@purplestreak.com>, iesg@ietf.org
References: <201608090602.u7962mQc025110@rumpleteazer.rhmr.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <99f5a0b1-5617-4d2b-fa54-005929273f16@nostrum.com>
Date: Thu, 06 Oct 2016 14:27:04 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <201608090602.u7962mQc025110@rumpleteazer.rhmr.com>
Content-Type: multipart/alternative; boundary="------------B070C03447AD44EE989EBEE6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/jVqYespu1_N9xOBbXXWZrlKux5s>
Cc: draft-ietf-avtext-rid.all@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] Security review of draft-ietf-avtext-rid-04
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: Thu, 06 Oct 2016 19:27:09 -0000
Thanks for the review! Responses inline. On 8/9/16 01:02, Hilarie Orman wrote: > "Abstract > This document defines and registers two new RTCP SDES items. One, > named RtpStreamId, is used for unique identification of RTP streams. > The other, RepairedRtpStreamId, can be used to identify which stream > a redundancy RTP stream is to be used to repair. > > Security considerations: > The actual identifiers used for RtpStreamIds (and therefore > RepairedRtpStreamIds) are expected to be opaque." > > "Opaque" seems to mean "no one cares what it is." Nonetheless, a > protocol should give some guidance about this. Taking the value from > a global 64-bit counter, for example, could leak information about the > global state of the machine. Having a short counter for each session > with a starting value of 0 would probably be OK. Having a short > counter start at a random value and wraps around would probably be OK. Thanks! If you look at the -05 version (which came out back in July), you'll see that we added some more explicit text around these identifiers. That version and subsequent ones have indicated: In many cases, a one-byte identifier will be sufficient to distinguish streams in a session; implementations are strongly encouraged to use the shortest identifier that fits their purposes. Implementors are warned, in particular, not to include any information in the identifier that is derived from potentially user- identifying information, such as user ID or IP address. To avoid identification of specific implementations based on their pattern of tag generation, implementations are encouraged to use a simple scheme that starts with the ASCII digit "1", and increments by one for each subsequent identifier. In later versions, the security section was updated to call back to this recommended behavior: Although the identifiers defined in this document are limited to be strictly alphanumeric, SDES items have the potential to carry any string. As a consequence, there exists a risk that it might carry privacy-sensitive information. Implementations need to take care when generating identifiers so that they do not contain information that can identify the user or allow for long term tracking of the device. Following the generation recommendations inSection 3.3 <https://tools.ietf.org/html/draft-ietf-avtext-rid-08#section-3.3> will result in non-instance-specific labels, with only minor fingerprinting possibilities in the total number of used RtpStreamIds and RepairedRtpStreamIds. Does that seem a reasonable treatment to you, or would you like to see additional/different language? > The "terminology" section could be improved by EAFMA and RUP > (expanding a few more acronyms and removing unused phrases). MSID and > SSRC are not expanded; "encoded stream" is never used. Good catch on "encoded stream"! I have added additional text to the Terminology section: The following acronyms are also used: o CNAME: Canonical End-Point Identifier, defined in [RFC3550] o MID: Media Identification, defined in [I-D.ietf-mmusic-sdp-bundle-negotiation] o MSID: Media Stream Identifier, defined in [I-D.ietf-mmusic-msid] o RTCP: Real-time Transport Control Protocol, defined in [RFC3550] o RTP: Real-time Transport Protocol, defined in [RFC3550] o SDES: Source Description, defined in [RFC3550] o SSRC: Synchronization Source, defined in [RFC3550] /a
- [secdir] Security review of draft-ietf-avtext-rid… Hilarie Orman
- Re: [secdir] Security review of draft-ietf-avtext… Adam Roach