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

Benjamin Kaduk <kaduk@mit.edu> Thu, 01 November 2018 14:12 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520D2126BED; Thu, 1 Nov 2018 07:12:47 -0700 (PDT)
X-Quarantine-ID: <UEFEC_t5fYQp>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEFEC_t5fYQp; Thu, 1 Nov 2018 07:12:44 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B33C124D68; Thu, 1 Nov 2018 07:12:43 -0700 (PDT)
X-AuditID: 1209190c-779ff70000001b9d-09-5bdb09d90a67
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 24.F0.07069.9D90BDB5; Thu, 1 Nov 2018 10:12:42 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id wA1ECejZ020979; Thu, 1 Nov 2018 10:12:40 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) �by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wA1ECYC2008718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 1 Nov 2018 10:12:38 -0400
Date: Thu, 1 Nov 2018 09:12:34 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Richard Barnes <rlb@ipv.sx>
Cc: radiaperlman@gmail.com, draft-ietf-perc-double.all@ietf.org, The IESG <iesg@ietf.org>, secdir <secdir@ietf.org>
Message-ID: <20181101141234.GY45914@kduck.kaduk.org>
References: <CAFOuuo65wvwoVaO8dqDqv-K3c27ncsWju2VTCvbiLMn0oNmEDw@mail.gmail.com> <CAL02cgTCSSDrm0nv-51bM-vp--2QSAvoBi86xHJeO9muJGztiw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAL02cgTCSSDrm0nv-51bM-vp--2QSAvoBi86xHJeO9muJGztiw@mail.gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA01SbUgTYRznudu5Z8Oz83T4OBPxlBBpplm0DyUVCKMXSioqB9nlnrbpNu1u ioqBRmmaDNNCGwaJpqDmLHr9ENIISrMIKrJTe1GpHEl96J1p3Tl8+fb7/39vPC+QZBsoPbS7 3Fhw8Q4uTKtiNbokg6QZM6cHJcoovck1tgbPk8abbbOU8aJni/Fb+wfVVsp0zzuhNnV2/iFM zde9qr1krnazBTvspVhYl3VUa2v72qouHthWNlMnEVWgN7MeaCBiNqCm6gtUPdBClukj0GzV LTI0DAB0Z+odCA3jBKrzNFGKRcUko9Hhy0DBYTKuOveCVHA0k4CevH6/oCGZSuSpfhSm4Chm E+r45ZP3ENJy3feRAmXNMi0A9ZziFEwzkWjo0rQqZE1Fo/MzhCInmTjUPQ/rgRpqmBx0rUIR 6JgkdN/jVzcCxrvC613h9S57rwCyB8RbnBUGJ293iDjfIObzLhcWDBlpTrs7DVtKboCFK44N vwtGvuzwAwYCLpxO0UtmluJLxXKnH8RCgtPRP1/Kq4hjRZZyGy/a8oQSBxb9AEGSi6abn8sc beHLK7BQtEjFQRUXQzee7jCzjJV340KMi7GwyK6GkEN0EI6Z2UgBW3HZcbvDvUwTUKOEh8vh q+SnZ2mxmHeKdmuIHwaZ8Gz7vxYS3h6payVZlavIhfUxdIQSxyhSW4lrKU35RKhwsDIAYuTD RdHTiipc/mJLeQG5ipCrtOpRpcrNL1P6KnBgLnp9V7vvKsy2HKx+e+jZj6SCie1JwTOfhmzS wzoJTz2WqCN7+hpyX9X0DWdIbK2u7GNNPHHY1JU+FWcLNHS5esd8+zDI63+akNe+0bDzwRq1 OjAeN3kyBQyGJXbv/j0d6cuZZEaSCTSfkniif18L+Lvr81phf21WrzV7jlOJNj4jlRRE/j+X IbCnHwMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/9VUVMFhRUghKhdN4ARtK4zkGCy0>
Subject: Re: [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: Thu, 01 Nov 2018 14:12:47 -0000

Sorry for top posting; on phone.

To ask the obviius question: what kind of hardware was your testing on?
Did it include ARM CPUs/mobile devices?  Anything without aesni?

Thanks,

Benjamin

On Wed, Oct 31, 2018 at 03:29:58PM -0400, 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 <radiaperlman@gmail.com>
> 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.  Even that wouldn't work, however,
> because we do want the payload content to be integrity-protected
> end-to-end.  So you need to double up at least on the integrity check.
> 
> 
> 
> > 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.
> >
> 
> You're correct that the second encryption is duplicative, but in the
> testing I've done, it is not a substantial waste of resources.  As noted
> above, you need two integrity checks anyway, so if we're not going to rely
> on multiple primitives, that means multiple invocations of AES-GCM.  And in
> practice, an "integrity only" invocation of GCM, with everything in the
> AAD, is not noticeably faster or slower than a normal invocation that also
> encrypts.
> 
> Another benefit of the current scheme is that having the outer transform be
> identical to the base AES-GCM transform makes implementation easier for
> intermediaries.  They don't have to change their SRTP stacks, they just
> have to adapt packet processing a little bit to add the OHB logic.
> 
> So yes, in principle, it's a little duplicative, but in practice, the
> duplication doesn't matter and the symmetry you get from it is advantageous.
> 
> 
> 
> > 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
> > derived.
> >
> 
> The key derivation here is inherent to SRTP; it would be a much more
> significant change to SRTP processing logic to specify keys directly,
> rather than adapting the KDF.
> 
> The KDF adaptation is needed so that you can give the intermediary the HBH
> half of the master key (using something like draft-ietf-perc-dtls-tunnel
> <https://tools.ietf.org/wg/perc/draft-ietf-perc-dtls-tunnel/>), and it'll
> end up KDF'ing that to the right keys / IVs for the HBH transform.
> 
> 
> 
> > 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.
> >
> 
> The set of RTP header fields that get E2E protection is fixed, with a fixed
> bit layout.  There is a variable extension portion at the end, but that
> receives no E2E protection, so it's not included in the OHB.
> 
> 
> 
> > 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?
> >
> 
> Where are you seeing a claim that the OHB can help with extensions?  It's
> not impossible that it's there; earlier versions had this feature, but it
> was removed to simplify things.
> 
> If the text you have in mind is "OHB that expresses any changes made
> between the inner and outer transforms", then I think it's just
> approximation for brevity.  The exact changes that the OHB can express are
> defined elsewhere.
> 
> 
> 
> > 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.
> >
> 
> The hard line here is that whenever the plaintext changes (e.g., the PT
> header gets sent to a different value), then a different (key, IV) pair
> needs to get used.  Otherwise you have nonce reuse.
> 
> The requirement as written, however, is probably a bit too strong.  It
> presumes that each recipient is getting a different packet, which is very
> common in conferencing scenarios, but not universal.  I'll think about how
> to clarify.
> 
> Thanks,
> --Richard
> 
> 
> >
> >
> > 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
> > unmodified.
> >
> >