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