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

["Paul E. Jones" <[e-mail]>]

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" <[e-mail]>
To: "David Benham" <[e-mail]>; "Paul E. Jones" 
<[e-mail]>
Cc: "Vincent Roca" <[e-mail]>; [e-mail]; 
[e-mail]; "The IESG" 
<[e-mail]>
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