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

"Paul E. Jones" <> Wed, 01 May 2019 05:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA9E81200B1; Tue, 30 Apr 2019 22:01:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XiZoAxtuIxsr; Tue, 30 Apr 2019 22:01:02 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 661AC12027E; Tue, 30 Apr 2019 22:01:02 -0700 (PDT)
Received: from authuser (localhost [])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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" <>
To: Vincent Roca <>, David Benham <>
Cc:,, The IESG <>,
Date: Wed, 01 May 2019 05:00:55 +0000
Message-Id: <emde7bdf10-574d-4853-bbf0-cd4bdbe6ec86@sydney>
In-Reply-To: <>
References: <> <emb104d043-b701-4e92-9e08-1e1815c2981f@sydney> <> <em0afb83b5-7014-4039-88b4-5ae3d87a6b0b@sydney> <> <> <>
Reply-To: "Paul E. Jones" <>
User-Agent: eM_Client/7.2.34711.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB68F8FC6C-889A-4BB4-89FE-A532229564CD"
Archived-At: <>
Subject: Re: [secdir] Secdir last call review of draft-ietf-perc-private-media-framework
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 May 2019 05:01:07 -0000


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


------ Original Message ------
From: "Vincent Roca" <>
To: "David Benham" <>; "Paul E. Jones" 
Cc: "Vincent Roca" <>;;; "The IESG" 
Sent: 3/4/2019 9:02:16 AM
Subject: Re: Secdir last call review of 

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