Re: [secdir] Secdir review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05

Varun Singh <varun@comnet.tkk.fi> Wed, 26 June 2013 17:43 UTC

Return-Path: <varun@comnet.tkk.fi>
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 9406C11E80F5; Wed, 26 Jun 2013 10:43:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwpketrAEoBo; Wed, 26 Jun 2013 10:43:28 -0700 (PDT)
Received: from smtp-out-02.aalto.fi (smtp-out-02.aalto.fi [130.233.228.121]) by ietfa.amsl.com (Postfix) with ESMTP id 2D78D21F9DBB; Wed, 26 Jun 2013 10:43:27 -0700 (PDT)
Received: from smtp-out-02.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 6D6BA271515_1CB283EB; Wed, 26 Jun 2013 17:43:26 +0000 (GMT)
Received: from smtp.netlab.hut.fi (sx2.tct.hut.fi [130.233.154.177]) by smtp-out-02.aalto.fi (Sophos Email Appliance) with ESMTP id 4DC7D27106F_1CB283EF; Wed, 26 Jun 2013 17:43:26 +0000 (GMT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 453FE1E142; Wed, 26 Jun 2013 20:43:26 +0300 (EEST)
X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi
Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LeTBDjw9eSWZ; Wed, 26 Jun 2013 20:43:21 +0300 (EEST)
Received: from [192.168.0.10] (cs181253247.pp.htv.fi [82.181.253.247]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 8A3E41E13D; Wed, 26 Jun 2013 20:43:21 +0300 (EEST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Varun Singh <varun@comnet.tkk.fi>
In-Reply-To: <tslhagny6he.fsf@mit.edu>
Date: Wed, 26 Jun 2013 20:43:20 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <90938DE2-4AE6-4C45-B918-6C94CEB12D69@comnet.tkk.fi>
References: <tslhagny6he.fsf@mit.edu>
To: Sam Hartman <hartmans-ietf@mit.edu>
X-Mailer: Apple Mail (2.1283)
X-Mailman-Approved-At: Fri, 28 Jun 2013 08:04:22 -0700
Cc: draft-ietf-xrblock-rtcp-xr-discard-rle-metrics.all@tools.ietf.org, ietf@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 26 Jun 2013 17:43:34 -0000

Hi,

Thanks for the comments, comments inline.

On Jun 24, 2013, at 4:37 PM, Sam Hartman wrote:

> 
> 
> Please treat these comments as normal last-call comments.
> 
> I've been asigned as a security directorate reviewer for this draft.
> 
> This draft specifies a mechanism to indicate which packets were
> discarded in a RTP stream.  for the most part, this doesn't seem to have
> any security implications, and the text is clear.  I do have one
> concern.
> 
> Has the WG analyzed implications of providing feedback to an attacker on
> what specific SRTP packets are discarded?  In the past we've run into
> trouble with security systems that were too verbose in error reporting.
> As an example, in certain public-key crypto constructions knowing
> whether a packet produced a decoding error vs a signature error after
> decryption can provide an attacker generating forged packets valuable
> information to attack the system.
> 

In the draft, discarded packets are defined as: packets that were received but
dropped from the jitter buffer because they were either too early (for buffering) 
or too late (for playout). 

Since the timestamp field in the RTP header is not encrypted, 
the endpoint can discard the packet before decrypting or authenticating it.
Forged packets that are discarded are not reported by this metric block.


> It's quite possible that SRTP doesn't have problems in this regard.  I
> just want to confirm that the analysis has been done. 

Cheers,
Varun