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

Matthew Lepinski <mlepinski.ietf@gmail.com> Mon, 27 October 2014 00:18 UTC

MIME-Version: 1.0
In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CABC6E1809@MSMR-GH1-UEA03.corp.nsa.gov>
References: <CANTg3aCd4KODurkV4Qk5iteYofqU6zOoXoDunO+AK-f58XteWQ@mail.gmail.com> <3C4AAD4B5304AB44A6BA85173B4675CABC6E1809@MSMR-GH1-UEA03.corp.nsa.gov>
Date: Sun, 26 Oct 2014 20:18:07 -0400
Message-ID: <CANTg3aDV7tAW3ZEwMAS9bJrQFFJSdxLNsBsn=j8bC8XX7m9sHQ@mail.gmail.com>
From: Matthew Lepinski <mlepinski.ietf@gmail.com>
To: "Igoe, Kevin M." <kmigoe@nsa.gov>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/x04_abrD6Nw7Kq_jDvQvp8udrWk
Cc: "draft-ietf-avtcore-srtp-aes-gcm.all@tools.ietf.org" <draft-ietf-avtcore-srtp-aes-gcm.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SECDIR Review of draft-ietf-avtcore-srtp-aes-gcm-14
Precedence: list

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

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

On Fri, Oct 17, 2014 at 11:17 AM, Igoe, Kevin M. <kmigoe@nsa.gov> 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
> kmigoe@nsa.gov  | of thinking we used when we created them."
>                 |              - Albert Einstein -
> ----------------+--------------------------------------------------
>
> -----Original Message-----
> From: Matthew Lepinski [mailto:mlepinski.ietf@gmail.com]
> Sent: Thursday, October 16, 2014 4:39 PM
> To: iesg@ietf.org; secdir@ietf.org; draft-ietf-avtcore-srtp-aes-gcm.all@tools.ietf.org
> 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 /

[secdir] SECDIR Review of draft-ietf-avtcore-srtp… Matthew Lepinski
Re: [secdir] SECDIR Review of draft-ietf-avtcore-… Igoe, Kevin M.
Re: [secdir] SECDIR Review of draft-ietf-avtcore-… Matthew Lepinski