[secdir] Secdir review of draft-ietf-perc-double-10

Radia Perlman <radiaperlman@gmail.com> Wed, 31 October 2018 18:25 UTC

Return-Path: <radiaperlman@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F002112F1A5; Wed, 31 Oct 2018 11:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9bJpI56l-a78; Wed, 31 Oct 2018 11:25:14 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828AE12D4F2; Wed, 31 Oct 2018 11:25:10 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id d7-v6so12414969lfi.2; Wed, 31 Oct 2018 11:25:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=aC9u11AzXB3eFl4ieG8X0ka2VD/LPLJY94L4j90OSZM=; b=lMQGOZ8TrOBXQAP4F5BT4WDbXPbzMO0DKqa+r1Z1HvI6qYvSrJ5yGtWwkRZO0VUxy3 z5bVbzbEmewfxpaqTuVRK/ewmIaZbqDK6tiC1YqwcE2zXrNjG6QjridBXza0gjqEKNed PN92O53T5KcXt7u0BSyqIDgv4x0c+LuXOVvr9BmzctwvQbK6SpZ3l+ZsI7G5JBvGivcj ZbpWMvZVvFAJ41D4AEbzR6iMrHoYywyFDlBT39bMQFdYKeJnJce+EMrngrmerA9T5lRl EoCuxGL75S2yQMPUdTBpINm7a4lX4JSfejqc5oY994elUl4jtdd3m5oY3pC8Zas8jduK fFnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=aC9u11AzXB3eFl4ieG8X0ka2VD/LPLJY94L4j90OSZM=; b=poAHJFhIbR5FKpQ9WxaQdL2h3bHfcM2veflxsEwUh5tn2mSA9w62ELaJ+Axsk43bF4 /B47OM+YUx9qJierSwFvwEeNsxlQDcuU4wbc4iIhyhRZupSRniY6KcqBRoj0tfs5vwP0 pe8QY+C9wslEEoRNtD6jDMJWjtio4U+a0rMuErOryaQSHbZcDzPPwb4UJMtt1HfmVtln yp+oyMg6XVLHuRX/8kqEBEiso/Aj/DaRXbN8ruoMB3FtjWMNx1vkHQFmQRTLDtNfZmIS V7CGtG3BnkeHjcInmOcyRsEVuW8rzWkHkKumZRDhmN1mS216Ya0abxJozV4TQJnnBsT8 xnog==
X-Gm-Message-State: AGRZ1gJsK4ITrGnZUbdbIpXmKtVDXdXRmUMywaLTiAR4omeC/J/OML+o +/frLafHHQi2Z0LInSyILM+If+tMJMLqVcztwTlnEAkg
X-Google-Smtp-Source: AJdET5eBCFPvgq6c9Fs8n4k55UxVfZS9UyfTyTLzoC4hAt4iTNKTgMXkxrr7yxT8Dnkdd5dbhQ077FHd+0VkIVMaAOE=
X-Received: by 2002:a19:9609:: with SMTP id y9mr2479383lfd.114.1541010308350; Wed, 31 Oct 2018 11:25:08 -0700 (PDT)
MIME-Version: 1.0
From: Radia Perlman <radiaperlman@gmail.com>
Date: Wed, 31 Oct 2018 11:24:57 -0700
Message-ID: <CAFOuuo65wvwoVaO8dqDqv-K3c27ncsWju2VTCvbiLMn0oNmEDw@mail.gmail.com>
To: secdir@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-perc-double.all@ietf.org
Content-Type: multipart/alternative; boundary="00000000000006498a05798a6cdf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Y7sd6icGpDVP778yNrgkr-dPKjg>
Subject: [secdir] Secdir review of draft-ietf-perc-double-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 31 Oct 2018 18:25:17 -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 a syntax for doubly encrypting Secure Real Time
Protocol (SRTP) packets so that the inner (media) content is encrypted with
a key known only to the endpoints while some header content is encrypted
with a separate key known by both the endpoints and network relay points
called Media Distributors (with the outer encryption key (usually) changing
on each hop).

Below are details for consideration by the authors and other potential
security reviewers.

Substantive comments:

Page 2 First paragraph:
AES-GCM is the only specified cryptographic mode, but may not be the
appropriate mode to use in distributing this content because there may be
cases where we want to guarantee the integrity of the data end-to-end while
allowing intermediaries to see the content. To support this case, it might
make sense to allow the encryption and integrity protection keys to be
separate so that an intermediary might be given the encryption key but not
the integrity protection key.

As noted in section 8, the inner payload ends up being encrypted twice
(which is a substantial waste of resources). It might make more sense to
include the inner encrypted payload as additional authenticated data in the
outer invocation of AES-GCM to avoid that overhead.

Page 5 section 3.1 Key Derivation:
This section specifies how the end-to-end and hop-by-hop keys must be
derived from a single "master key". But this could only be true at the
source node and would imply the intermediaries are not allowed to see the
master key and the destination would not need to see the master key
(because by the time the destination receives the message the key used for
the outer encryption would be different.

I would expect that the inner and outer keys would be negotiated
independently and there would be no master key from which they are all

Page 5 Section 4:
If the set of RTP header fields is fixed and there is a fixed ordering to
them, this is OK. But it wasn't obvious to me how to reflect in the OHB the
difference between a new header field being added. And if fields are
deleted (and therefore added to the OHB), it's not obvious in what order
they should be reinserted by the ultimate recipient.

Page 6 Section 5:
The second paragraph says the extensions are truncated when computing the
inner checksum while the third paragraph says there is information in the
OHB to reconstruct the original extensions to allow verification of the
inner checksum. Either of these two techniques could be used, but the
source and destinations must use the same one. Or is this specifying that
some combination be used?

Page 9 paragraph 1 says:
"A Media Distributor that decrypts, modifies, and re-encrypts packets
   in this way MUST use an independent key for each recipient, SHOULD
   use an independent salt for each recipient, ..."
This represents substantial additional work for the Media Distributor. If
it is important to use an independent key for each recipient, some
justification should be noted. The likely one is that it prevents one
recipient from undetectably modifying the copy of data sent to another
recipient. This protection is not needed in all scenarios, and so perhaps
should be optional.

Editorial Comments / Typos:

Page 2 Second paragraph:
There may be a word missing. What is "the double"? Also, throughout the
document the  protocol is referred to as "double", which if intended should
probably be listed in section 2.

Page 2 Last line:
If multiple Media Distributors are allowed, hop by hop also refers to the
path between two Media Distributors.

Page 8 Section 5.2 bullet 2:
<fields are allowed> -> <fields that are allowed>

Page 11 section 7.1 paragraph 1
I suspect there is a word or two missing. "it MUST be encrypted the packet
in repair mode" sounds like something Yoda would say.

Page 13 section 9 last paragraph says:
"If the MD doesn't modify any header fields,
   then an MD that supports AES-GCM could be unused unmodified."
This should say something like ...could use the same key and relay packets