[secdir] review of draft-ietf-avt-srtp-big-aes-05.txt

"Hilarie Orman" <hilarie@purplestreak.com> Tue, 04 January 2011 22:21 UTC

Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 1A7003A6C1B; Tue, 4 Jan 2011 14:21:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id LGWUPxol4y09; Tue, 4 Jan 2011 14:21:54 -0800 (PST)
Received: from out01.mta.xmission.com (out01.mta.xmission.com []) by core3.amsl.com (Postfix) with ESMTP id F1F053A6C5C; Tue, 4 Jan 2011 14:21:53 -0800 (PST)
Received: from mx02.mta.xmission.com ([]) by out01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1PaFIP-0001Fs-62; Tue, 04 Jan 2011 15:24:01 -0700
Received: from 166-70-57-249.ip.xmission.com ([] helo=fermat.rhmr.com) by mx02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1PaFIN-0005o7-35; Tue, 04 Jan 2011 15:24:00 -0700
Received: from fermat.rhmr.com (localhost []) by fermat.rhmr.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p04MQef9028796; Tue, 4 Jan 2011 15:26:40 -0700
Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id p04MQe4E028795; Tue, 4 Jan 2011 15:26:40 -0700
Date: Tue, 4 Jan 2011 15:26:40 -0700
Message-Id: <201101042226.p04MQe4E028795@fermat.rhmr.com>
X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f
From: "Hilarie Orman" <hilarie@purplestreak.com>
To: iesg@ietf.org, secdir@ietf.org
X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx02.mta.xmission.com; ; ; ip=; ; ; frm=hilarie@purplestreak.com; ; ; spf=none
X-XM-DomainKey: sender_domain=purplestreak.com; ; ; sender=hilarie@purplestreak.com; ; ; status=error
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: ;iesg@ietf.org, secdir@ietf.org
X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600)
X-SA-Exim-Scanned: Yes (on mx02.mta.xmission.com)
Subject: [secdir] review of draft-ietf-avt-srtp-big-aes-05.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Hilarie Orman <hilarie@purplestreak.com>
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 04 Jan 2011 22:21:58 -0000

Security review of draft-ietf-avt-srtp-big-aes-05.txt

Do not be alarmed.  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

This is a very well-written document about using AES-192 and AES-256
with RTP, and I have only a few comments.

There is no comment on why AES-192 might be used.  There is a comment
about AES-128 vs. AES-256, but AES-192 seems to fall into a useless
middle ground.  I'd like to see some comment about it.

Section 3.1 "Usage Requirements" might be easier to understand if it
said that "When AES_192_CM is used for encryption, the key derivation
function MUST have a cryptographic strength of at least 192 bits;
AES_192_CM has this strength, AES_128_CM does not."  Similarly for

It would be helpful to note which data items are specific to SRTP.
The draft says that it uses the terminology of "Section 4.1.1 of
[RFC3711]", but oddly enough, the "SSRC" is not defined in that
document, either.  One must go back to RFC3550 for its definition.

I was flummoxed by the math of "if kdr=0 then (index DIV kdr) = 0".
RFC3711 section 4.3.1 does explain it; it's kind of confusing to have to
switch back and forth between the two documents.

The block counter "b_c" is two octets, but the "default key lifetime"
is 2^31.  Is this perhaps the "maximum" key lifetime?  Should
implementors introduce an internal counter to keep track of the
history of key usage (across sessions?)?  Perhaps earlier documents
explain this?