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

Sam Hartman <hartmans-ietf@mit.edu> Mon, 24 June 2013 13:38 UTC

Return-Path: <hartmans@mit.edu>
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 982A621F9EDE; Mon, 24 Jun 2013 06:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 RZ9Dkg3mpIku; Mon, 24 Jun 2013 06:38:15 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id B196421F9EC2; Mon, 24 Jun 2013 06:38:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 77E23200E0; Mon, 24 Jun 2013 09:34:06 -0400 (EDT)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTy0ix9-IkPT; Mon, 24 Jun 2013 09:34:05 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 24 Jun 2013 09:34:05 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9F93A80952; Mon, 24 Jun 2013 09:37:49 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: ietf@ietf.org, secdir@ietf.org
Date: Mon, 24 Jun 2013 09:37:49 -0400
Message-ID: <tslhagny6he.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: draft-ietf-xrblock-rtcp-xr-discard-rle-metrics.all@tools.ietf.org
Subject: [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: Mon, 24 Jun 2013 13:38:21 -0000

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.

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