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

"Paul E. Jones" <paulej@packetizer.com> Wed, 01 May 2019 05:01 UTC

Return-Path: <paulej@packetizer.com>
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 DA9E81200B1; Tue, 30 Apr 2019 22:01:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com
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 XiZoAxtuIxsr; Tue, 30 Apr 2019 22:01:02 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (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 661AC12027E; Tue, 30 Apr 2019 22:01:02 -0700 (PDT)
Received: from authuser (localhost [127.0.0.1])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1556686858; bh=ltGw5eqAVq1w+FiMnspIlb6YXfHnBvKMvN3agE2WSSI=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=C1B1KtXtTaMeebrAt3NMiXq0YiSXvosuCncSso9L/fgla8OnnaT6evFRaVuw3iezL bjBrlsA8qKqYFo8rqEtdrethuM8ISk5dPIf4K7YQpdGhY/TNfLb/CM/mlai2dH7N7w YMkDhSKm9Qyx+xzGyObv2uijUqb+VQ6NEGI2oVWg=
From: "Paul E. Jones" <paulej@packetizer.com>
To: "Vincent Roca" <vincent.roca@inria.fr>, "David Benham" <dabenham@gmail.com>
Cc: secdir@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org, "The IESG" <iesg@ietf.org>, aamelnikov@fastmail.fm
Date: Wed, 01 May 2019 05:00:55 +0000
Message-Id: <emde7bdf10-574d-4853-bbf0-cd4bdbe6ec86@sydney>
In-Reply-To: <D519986E-441D-4923-A556-6F3793B451BD@inria.fr>
References: <155014077570.26619.9407568904769535504@ietfa.amsl.com> <emb104d043-b701-4e92-9e08-1e1815c2981f@sydney> <6882A552-80DF-4322-9683-13D8E655F2DB@inria.fr> <em0afb83b5-7014-4039-88b4-5ae3d87a6b0b@sydney> <DB650EB5-5E7E-46B3-A8B7-524B36D2AC26@inria.fr> <CAM5V9Z8Dz=qSB3n+8RGGx0d=1PgLds01asgOGDyhFL81g=TiuQ@mail.gmail.com> <D519986E-441D-4923-A556-6F3793B451BD@inria.fr>
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
User-Agent: eM_Client/7.2.34711.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB68F8FC6C-889A-4BB4-89FE-A532229564CD"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/MYrsVX_Q1q6_vVrCBwo-gSlRjFQ>
Subject: Re: [secdir] Secdir last call review of draft-ietf-perc-private-media-framework
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: Wed, 01 May 2019 05:01:07 -0000

Vincent,

I was finally able to get back to this and prepare an updated draft.  I 
make changes as outlined below that should appear in -10 shortly.

Section 8.1: Will add an introductory sentence.
Section 8.1: Good point. That's confusing, as mutual authentication is 
required in DTLS-SRTP. The value goes beyond cascading, too, and is 
really a tool to help mitigate against DoS.  I'll re-word this paragraph 
substantially.
Section 8.2.2: You're right. I'll make a clear requirement statement on 
replay protection earlier in the body of the document and update that 
text.
Section 8.2.3: Good point. And there is a limited mitigation for this, 
which is to re-key the conference periodically.  I'll add another 
paragraph about that, since it might not be obvious.

Thanks!
Paul

------ Original Message ------
From: "Vincent Roca" <vincent.roca@inria.fr>
To: "David Benham" <dabenham@gmail.com>om>; "Paul E. Jones" 
<paulej@packetizer.com>
Cc: "Vincent Roca" <vincent.roca@inria.fr>fr>; secdir@ietf.org; 
draft-ietf-perc-private-media-framework.all@ietf.org; "The IESG" 
<iesg@ietf.org>
Sent: 3/4/2019 9:02:16 AM
Subject: Re: Secdir last call review of 
draft-ietf-perc-private-media-framework

>Hello David, Paul, all,
>
>I gave a look at version -09 of your I-D, here are a few comments.
>
>Summary: Almost ready
>
>** Section 8.1
>  There is a sentence introducing section 8.2, but none for section 8.1. 
>For instance it is not explicitely
>explained what is meant by « 3rd party attack ». I suggest adding a 
>sentence.
>
>** Section 8.1
>You’re saying that "If mutual DTLS authentication is not employed… ». 
>Is it really an optional mechanism?
>I must admit I haven’t read the rest of your I-D where this is probably 
>explained, I’m just a bit surprised here.
>
>** Section 8.2.2
>It is suggested but not clearly said that the replay protection of 
>Section 3.3.2/[RFC3711] MUST be used.
>The sentence can be understood as replay protection is mandatory, 
>Section 3.3.2 of [RFC3711] is an example
>of such a mechanism.
>I don't think this is what you mean.
>
>** Section 8.2.3
>Saying that "The delayed playout attack is a variant of the replay 
>attack" is IMHO misleading.
>Delaying and re-sending a packet already sent are two different attacks 
>(and the fact that replay
>protection is of no help against delayed packets is a good sign of 
>these differences).
>I'd remove this sentence altogether.
>
>
>Otherwise, concerning your previous comment:
>
>
>>Follow up question regarding your general comments on sect 8.1 and 8.2 
>>which we have not yet addressed in -09 ;
>>
>> > Attacks of section 8.1 seems more realistic to me than attacks of 
>>section 8.2
>> > because of a weaker attacker model: the attacker is outside of the 
>>systems,
>> > and not necessarily on the path.
>> > Therefore I would have liked to see more details in section 8.1, 
>>that’s all.
>>
>>You're asking for greater detail in sect 8.1 precisely because you 
>>estimate that third-party attacks (aka outsiders to a given 
>>conference) are more likely/common than the attacks we covered in the 
>>subsequent 8.2 section.   Is that correct?
>>
>>If so, I think we could restate some of what we have in sect 8.1 to 
>>make it flow better and/or be clearer.   But it is not clear to us 
>>what we left out detail-wise, or if we left out other attack examples.
>>
>>With PERC's HBH integrity checks, authentication as well as HBH and 
>>E2E encryption, we can quickly describe in text the 
>>prevention/mitigation of attacks on the confidentiality of the 
>>media/content - PERCs reason to be - to explain some of the brevity.
>>
>>Could you help point us in the right direction with an example or two 
>>of the things we should do to detail/elaborate sect 8.1.
>
>[VR] I was surprised to see for instance 8 lines of text in section 
>8.2.2 or 8.2.4 to describe attacks
>that cannot take place because of the PERC design. That being said, I 
>see that version -09 has a
>more detailed section 8.1 which is fine.
>
>Cheers,
>
>    Vincent