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

Matthew Lepinski <> Mon, 27 October 2014 00:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 754C21A1B1F; Sun, 26 Oct 2014 17:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zZS-SOMdFPmp; Sun, 26 Oct 2014 17:18:09 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 290861A1B2A; Sun, 26 Oct 2014 17:18:09 -0700 (PDT)
Received: by with SMTP id x13so793964wgg.20 for <multiple recipients>; Sun, 26 Oct 2014 17:18:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LZVz2P6CdsLGP/QrP6ezcWeARnW82F94nNRbXlbLaw4=; b=fc5/rMGSMWnf8dDe+cv+37apx7oWT63EU29+yCrLG0oNfcwv5KtDR3lNRhAE73Deug celFe4e0VyS403rJxMmdVwifyhCtGRZvcBfxSEIvytQ4L4MNtnTEajXSJL7M3f54h/jQ 5j2QeybWv4Rm7wEsCQrz+cTpOnJlsCEaE3W5S0y7PB9TytaeYwUDEGllcmNcWCjSv3ZL R6RYfMm6NiIPcQ1nVGFSLfNui8/jqpXe4rTONKol6hf9j8tpTBdYhC79iQvtefGeaErF HUfPueJtfns2STmFMlZ2GBgH5WUm98YT2IgszlLmxnSCUioPawzVih1eihxnVQdpLDsk IPYg==
MIME-Version: 1.0
X-Received: by with SMTP id vy4mr19279209wjc.36.1414369087763; Sun, 26 Oct 2014 17:18:07 -0700 (PDT)
Received: by with HTTP; Sun, 26 Oct 2014 17:18:07 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Sun, 26 Oct 2014 20:18:07 -0400
Message-ID: <>
From: Matthew Lepinski <>
To: "Igoe, Kevin M." <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] SECDIR Review of draft-ietf-avtcore-srtp-aes-gcm-14
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Oct 2014 00:18:11 -0000

I gave this a bit more thought and I also am not able to come up with
any good security reason to keep the master salt secret.

I believe that any of the three text changes that you suggest would be
perfectly fine. Any of them would be an improvement over the current

Thanks for taking the time to address this minor concern.
- Matt Lepinski

On Fri, Oct 17, 2014 at 11:17 AM, Igoe, Kevin M. <> wrote:
> I have no problems with the changes you suggest.
> As to the use of a secret salt, sction 3.2.1 of RFC 3711 says the
> master salt may be either public or secret.  Annoyingly, it never
> again mentions any distinction betwixt public and secret master keys.
> Neither myself nor my colleagues could come up with a sound security
> reason for using a secret master salt, but all secret vslues need to
> be properly erased.  I see three (3) options:
> a) change the first bullet of section 14.1 to read:
> "  - The master salt MUST be properly erased when it is no longer needed."
> b)  Adding the following two (2) sentences to the end of the first
> paragraph of section 14.1.
>   "RFC 3711 provides for the use of either a public master salt or a
>   secret master salt.  When there is any doubt as to which option has
>   been selected, for the purposes of this section the master salt should
>   be treated as if it was secret."
> c) Put at the end of the first bullet:
>   "When in doubt as to whether the master salt is public or secret,
>    it should be erased as if it was secret."
> No real preference, but option a) is the easiest typographically.
> ----------------+--------------------------------------------------
> Kevin M. Igoe   | "We can't solve problems by using the same kind
>  | of thinking we used when we created them."
>                 |              - Albert Einstein -
> ----------------+--------------------------------------------------
> -----Original Message-----
> From: Matthew Lepinski []
> Sent: Thursday, October 16, 2014 4:39 PM
> To:;;
> Subject: SECDIR Review of draft-ietf-avtcore-srtp-aes-gcm-14
> 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 /