[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
- [secdir] Secdir last call review of draft-ietf-pe… Vincent Roca
- Re: [secdir] Secdir last call review of draft-iet… Benjamin Kaduk
- Re: [secdir] Secdir last call review of draft-iet… Paul E. Jones
- Re: [secdir] Secdir last call review of draft-iet… Vincent Roca
- Re: [secdir] Secdir last call review of draft-iet… Paul E. Jones
- Re: [secdir] Secdir last call review of draft-iet… Vincent Roca
- Re: [secdir] Secdir last call review of draft-iet… Paul E. Jones
- Re: [secdir] Secdir last call review of draft-iet… David Benham
- Re: [secdir] Secdir last call review of draft-iet… Vincent Roca
- Re: [secdir] Secdir last call review of draft-iet… Paul E. Jones
- Re: [secdir] Secdir last call review of draft-iet… Vincent Roca
- Re: [secdir] Secdir last call review of draft-iet… Paul E. Jones
- Re: [secdir] Secdir last call review of draft-iet… Vincent Roca
- Re: [secdir] Secdir last call review of draft-iet… Paul E. Jones
- Re: [secdir] Secdir last call review of draft-iet… Vincent Roca