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

From: Radia Perlman <[email-masked]>
Date: Wed, 31 Oct 2018 11:24:57 -0700

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

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

---

From: Richard Barnes <[email-masked]>
Date: Wed, 31 Oct 2018 15:29:58 -0400

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 <[email-masked]>
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

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.

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

> independently and there would be no master key from which they are all

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.

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

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

> recipient. This protection is not needed in all scenarios, and so perhaps

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

---

From: Radia Perlman <[email-masked]>
Date: Wed, 31 Oct 2018 18:44:41 -0700

On Wed, Oct 31, 2018 at 12:30 PM Richard Barnes <[email-masked]> wrote:

> Hi Radia,
>
> Thanks for the review.  Responses to the substantive comments inline.
> Will take a look at the editorial ones in a bit.
>
>
> 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
key.

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

Radia