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

Radia Perlman <> Thu, 01 November 2018 01:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42017130DF3; Wed, 31 Oct 2018 18:44:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Nii8WodPbqjM; Wed, 31 Oct 2018 18:44:55 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 85BF2130DDE; Wed, 31 Oct 2018 18:44:55 -0700 (PDT)
Received: by with SMTP id n3-v6so13114048lfe.7; Wed, 31 Oct 2018 18:44:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SrYCpfA7hulVPIHKm44A36t4DC1yz3FQ0n46FVum4vY=; b=LoUObtb+sqNJrjgs7g4rLadHT1VOKjal1USnZdja6G5BzaKqWOuWgDuoNC4DV7ftIB x+Ky/JaY+2Vr4sTAcAYdEMeh8ff0C3u5TgmGeS7oK2EJNeuaaPRGUkqGdVUN+sRVUJoS 5u7FXbce0WFjYnAovyrH9mzob8z06ZLBotyeiSG31VztmUYmepmUZJpcLIVBO4Z19xkn qFe7Mknp+pBC3oid6vSBdX+S/wT65xwqgkiy550i/k8dlSDKANuq9NKTmSt2PiLsun/Y zU5/sswdTmaGxDP6qF04jhdsbzzdB8PuIOPbJ2MATGE1R9iWbiGezItg9Y3TIiZw9dn2 C58Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SrYCpfA7hulVPIHKm44A36t4DC1yz3FQ0n46FVum4vY=; b=LvT0hZ7EVTQy/RM6Jm5OkEtrXwGRsabegpITHOfDBE6uDCeWQ5OYhRoJ7QK+4ZMBb6 DwXUlyczPbNlGOQ7kNii7ZTaPmhgfd7wHyhebpeAso0+5W85JY3TUAWDi9dImqvL977m U4XLISL/9o+vw8NmH2izuGU1qPM/lcA8QgBeJch+ave/1VvdH3N+o5L4DWrXsKnv3gDB 5OQgR4wK7IcA9SjYuZdC+/kDcP9hBsuhOadcr2Z1tejQBt8odpKxtwR9rtjym21g+ev2 dXCTSKYdYP7rLHIvfNjjZN/VL+0QYmvejVU3dtA+cUEsgiTl1lXONRSE8LLuX0zTzQoi X/QA==
X-Gm-Message-State: AGRZ1gJTgaKVisKFpgUf5uNVWuaIScXfgBpfDZYnDP7S/IOr/xq+Cdgh UiNq20+5v0q38fRJze4JjfIge2dOhiHEmwMEre8=
X-Google-Smtp-Source: AJdET5cslpF414McgwFpNn5m0IiggGs0Wdkj0eEmj0RoPicIZnVspYkJ2DU1Rxdzh4Xu/vrYKePWrHTGQ15Fthfk8fY=
X-Received: by 2002:a19:d8ea:: with SMTP id r103mr3449767lfi.146.1541036693665; Wed, 31 Oct 2018 18:44:53 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Radia Perlman <>
Date: Wed, 31 Oct 2018 18:44:41 -0700
Message-ID: <>
To: Richard Barnes <>
Cc:, The IESG <>,
Content-Type: multipart/alternative; boundary="000000000000b63d6e05799090f3"
Archived-At: <>
Subject: Re: [secdir] Secdir review of draft-ietf-perc-double-10
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Nov 2018 01:44:58 -0000

On Wed, Oct 31, 2018 at 12:30 PM Richard Barnes <> wrote:

> Hi Radia,
> Thanks for the review.  Responses to the substantive comments inline.
> Will take a look at the editorial ones in a bit.
> On Wed, Oct 31, 2018 at 2:25 PM Radia Perlman <>
> wrote:
>> 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.
> I think you mean we would give the intermediary the integrity key, not the
> encryption key :)  Since we want to enable the intermediary to modify
> things, but not read the content.

No, I really mean an intermediary might need the encryption key, so it can
read the contents, but not the integrity key, because it shouldn't modify
the contents.  An example is an intermediary scanning for viruses.  It
needs to see the contents, but is not going to modify the contents. That
way the integrity check really means that the source is vouching for the
authenticity of the content ("end-to-end integrity")

I can't think of any cases of an intermediary needing to modify encrypted
contents, and therefore needing the integrity key but not the encryption

I'll look at the rest of the comments later..