[secdir] Secdir last call review of draft-ietf-perc-private-media-framework-08

Vincent Roca <vincent.roca@inria.fr> Thu, 14 February 2019 10:39 UTC

Return-Path: <vincent.roca@inria.fr>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D6012870E; Thu, 14 Feb 2019 02:39:35 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Vincent Roca <vincent.roca@inria.fr>
To: secdir@ietf.org
Cc: iesg@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155014077570.26619.9407568904769535504@ietfa.amsl.com>
Date: Thu, 14 Feb 2019 02:39:35 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/-aZOgK65QIPqtKdIPo6VpCopQuw>
Subject: [secdir] Secdir last call review of draft-ietf-perc-private-media-framework-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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, 14 Feb 2019 10:39:36 -0000

Reviewer: Vincent Roca
Review result: Has Issues

Hello,

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.

Summary: **Has Issues**

I have several significant concerns with respect to the Security Considerations
section.

** Section 8.1
Why is it said that:
        "A successful attacker might be able to get the Media Distributor to
        forward such packets."
Is it really possible? That would be a big design issue! In fact the following
sentence suggest the opposite and I think this is essentially an erroneous
manner to present things. Please see comments on Section 8.2.4 on saying things
the other way round.

The same comment applies to the remaining two paragraphs. I suggest the authors
explain that the proposal prevents an attacker to claim being a regular Media
Distributor and therefore to fool endpoints because ...".

** Section 8.2.2.
Is the following sentence correct:
   The mitigation for a replay attack is to prevent old packets beyond a
   small-to-modest jitter and network re-ordering sized window to be
   rejected.
Is "prevent [...] to be rejected" correct? I'd say "... to be delivered"
instead.

Another comment. Replay protection seems to be based on timing considerations
rather than on the use of unique sequence numbers that must not be replayed
(except if a wrapping to zero occurs of course). Is that correct? Additionally,
is this mechanism carefully described in this document? Since it is explained
that E2E replay protection MUST be provided, it's essential to be very clear on
how to perform this. Failing to do so is a big issue.

** Section 8.2.3
It is said that "a Media Distributor can select to not deliver a particular
stream for a while." That's perfectly true, yet is this a "Delayed playout
attack"? I'd rather call it a Media Distributor censorship attack, or something
along this line. The main idea behind the attack is not to delay a stream but
to censor a source.

In the second paragraph I don't understand why it is said that:
        "the receiver believing that it is what was said just now, and only
        delayed due to transport delay."
Any RTP packet contains a timestamp (whose integrity is protected end-to-end if
I understand correctly), and this timestamp is used by the receiver to identify
timing issues. The fact a packet is delayed (significantly) by a Media
Distributor cannot be misinterpreted by a receiver as a "what was said just
now". The receiver immediately identifies this delay.

I now understand the title ("delayed playout") but I really suspect this is a
mistake as (too much) delayed packets will not be played at all.

** Section 8.2.4:
I don't like the way this section is written. It first explains what a Media
Distributor could do if it could alter a certain header field (in this case
SSRC), it details the consequences, to finally explain that this is not
possible. This Security Discussion section is essentially meant to discuss
remaining security issues or highlight specific aspects, not what could happen
with a different, non secure, design. This text could also be written the other
way round: "By including the SSR field into the integrity check, PERC prevents
splicing attacks where...".

** Missing in 8.2
The RTCP flows are not encrypted end-to-end (unlike data flows) but only
hop-by-hop. Consequently, a malicious Media Distributors may corrupt an RTCP
packet content (e.g., reception statistics in RR) or forge malicious RTCP
packets which may trigger various effects at a sender. There are other types of
RTCP packets that may be attacked as well with various consequences. None of
this is explained in section 8.2. "Media Distributor Attacks".

** General comments about 8.1 and 8.2
Insider attacks are a powerful form of attacker model with severe consequences.
This is not a big surprise. I'd be more interesting in a detailed 8.1 section,
more likely to happen (weaker attacker model).

Suggestion:

** 8.2. Instead of:
        "The Media Distributor can attack the session in a number of possible
        ways."
I suggest:
        "A malicious or compromised Media Distributor can ..."

Typos:

** Intro: s/virutalized/virtualized/

** Section 2: s/and is never allowed have access/and is never allowed to have
access/

** 8. Security Considerations:
        s/could incorrectly assuming/could incorrectly assume/

        s/This attack is be mitigated/This attack is mitigated/

        s/when an already received packets/when an already received packet/

Other comments:

** Section 6, intro: (it's a detail, but...)
I don't think that the use of "and so forth" is adequate in a specification
that aims to be exhaustive. The list of items addressed in section 6 is
finished.

Cheers,

  Vincent