[secdir] SECDIR Review of draft-ietf-avtcore-srtp-aes-gcm-14

Matthew Lepinski <mlepinski.ietf@gmail.com> Thu, 16 October 2014 20:39 UTC

Return-Path: <mlepinski.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3BEC71A892E; Thu, 16 Oct 2014 13:39:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id raCO-xulebIy; Thu, 16 Oct 2014 13:39:27 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827F31A899C; Thu, 16 Oct 2014 13:39:26 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id h11so2535419wiw.0 for <multiple recipients>; Thu, 16 Oct 2014 13:39:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=KFaGvt+BdPWhjDsfyjCEFFxPNKZ/lFyGGazZKvAT2BU=; b=UhG6yn/GEU9dRV2ux3mD58x8los/RujSKRM/vkADihlQLdsj0zXEzM0sbeRwClyTHP GF4SMFD1b7Q6Q+kaMpL/RIHAuHLUli4zE7H1imltaJumKHRHKhMw5VIJVYNz5gEYDBu5 J8gBmWUekDj6CBLRiiKSRUbNgtpuuhqQ0X/x+KUEwCPgIELyTxtiUyEXg4riqvE6Zqud jRtav7wgaxCAKIsG/HoNRHqTG6Vtmocf0dZJQoycSyl1AHOj1EnOtDZC/FSr40boH2e1 X9v0kjwOGhaQ0g7TbeSu9hj8VjisOfD8chWww5+ufOe9GbF/f3Z7czQk3RZPZMnlhztQ VJXg==
MIME-Version: 1.0
X-Received: by with SMTP id e14mr4894394wjx.106.1413491965146; Thu, 16 Oct 2014 13:39:25 -0700 (PDT)
Received: by with HTTP; Thu, 16 Oct 2014 13:39:25 -0700 (PDT)
Date: Thu, 16 Oct 2014 16:39:25 -0400
Message-ID: <CANTg3aCd4KODurkV4Qk5iteYofqU6zOoXoDunO+AK-f58XteWQ@mail.gmail.com>
From: Matthew Lepinski <mlepinski.ietf@gmail.com>
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-avtcore-srtp-aes-gcm.all@tools.ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/_fGU52Euiz38YB2CyY3Z_YlQW2Y
Subject: [secdir] SECDIR Review of draft-ietf-avtcore-srtp-aes-gcm-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 16 Oct 2014 20:39:28 -0000

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 comments.

This document specifies the use of the Advanced Encryption Standard
(AES) in both Galois Counter Mode (GCM) and CBC Counter Mode (CCM) as
an Authenticated Encryption with Additional Data (AEAD) cipher-suite
for the SRTP protocol. This is the first AEAD specification for SRTP.
However, this specification is consistent with other AEAD work in the
IETF (i.e., RFC 5116).

I found no significant issues in the review of this document and
believe that it is ready for publication.

Nits (consider the following suggestions):

Section 3b: s/(as well one or more /(as well as one or more /

Section 6: s/XORed to the plaintext to form /XORed with the plaintext to form /

Section 9.1: s/XORed to the 12-octet salt to form /XORed with the
12-octet salt to form /

Section 10.1: s/XORed to the 12-octet salt to form /XORed with the
12-octet salt to form /

Section 11: s/accept inputs with varying lengths /accept inputs of
varying lengths /

Section 14.1: You use the phrase "If the master salt is to be kept
secret". However, I am not sure how an implementer is supposed to
decide whether or not to keep the master salt secret. If you have any
reference on the ramifications of keeping / not-keeping the master
salt secret, it would be helpful to include such a reference.

Section 14.2: s/authentication value until by chance they hit a valid
/authentication value until, by chance, they hit a valid /