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

From: Vincent Roca <[email-masked]>
Date: Fri, 10 May 2019 09:37:38 +0200

Dear authors, all,

I’ve looked at the new -10 version of your I-D.

Summary: Ready with nits

** In section 8.1 it is said:

   "While confidentiality
   would not be compromised by failing to implement mutual
   authentication, employing it helps mitigate against denial of service
   attacks wherein a false entity sends a stream of packets that the
   would force a legitimate entity to spend time attempting to decrypt."

This is true only if authenticating a received packet is cheap, which is
not necessarily the case. And in section 5 « Authentication » you say that
"details of this are outside the scope of specification", so we are not
able to answer the above question: is authenticated really so cheap?
With certain authenticated encryption technics (e.g. MAC-then-Encrypt),
decrypting is required before checking data authenticity… So please
clarify.

NB: there's also a typo in above sentence: "that the would".

Finally, shouldn't this paragraph appear after the last one "A third
party could cause..." since they are both concerning the same DoS issue.
In that case you start with simple protections (rate limitation, heuristics)
then continue with (cheap) authentication.

** Section 8.2.3: the following sentence is unnecessarily obscur IMHO:
        "Within the window from last packet forwarded to the receiver and the
        latest received by the Media Distributor,..."
Why don't you simply say that the MD can choose, at some point of time, to
delay some packets by an arbitrary duration? Do we really need this notion
of "window »?

Cheers,

  Vincent

> Le 1 mai 2019 à 07:00, Paul E. Jones <[email-masked]> a écrit :
> 
> 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" <[email-masked] <mailto:[email-masked]>>
> To: "David Benham" <[email-masked] <mailto:[email-masked]>>; "Paul E. Jones" <[email-masked] <mailto:[email-masked]>>
> Cc: "Vincent Roca" <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; "The IESG" <[email-masked] <mailto:[email-masked]>>
> 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

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 12 May 2019 04:34:55 +0000

Vincent,

Once again, thanks for the feedback.  Please allow me to reply inline 
and, if you're OK with the text, I can prepare a new revision.

>decrypting is required before checking data authenticity… So please

Actually, after reading that original text, I think it is even 
misleading to suggest confidentiality is not compromised.  In terms of 
encryption, that would be true, but in terms of net effect, it would 
not: without verifying the certificate, an unwanted party could 
potentially engage in the conference.  I think this would be better text 
(replacing the entire paragraph):

Use of mutual DTLS authentication (as required by DTLS-SRTP) ensures 
that a
false endpoint or false Media Distributor cannot interact with a 
legitimate
Media Distributor or endpoint.  This helps mitigate against denial of 
service
attacks wherein a false entity sends a stream of packets that would 
force
a legitimate entity to spend time attempting to decrypt.

With respect to whether the DoS mitigation is true or not, I think it 
is.  If mutual authentication fails, then no media packets would flow at 
all, thus no wasted time decrypting packets; packets would likely get 
rejected without inspection.  If mutual authentication succeeds, then 
the cost isn't at issue here, anyway, since the point of the paragraph 
is to talk about a side benefit of mutual authentication.  While the 
specifics are outside the scope of the document, the assumption is that 
some mechanism is employed to enable checking the validity of 
certificates.

>NB: there's also a typo in above sentence: "that the would".

Thanks, I fixed that.

>then continue with (cheap) authentication.

Agreed, moving it makes more sense.

>delay some packets by an arbitrary duration? Do we really need this 

Definitely not essential.  I tried to make whole paragraph a little 
easier to read.  How about this:

While the Media Distributor can purposely stop forwarding media flows, 
it
can also select an arbitrary starting point to resume forwarding those
media flow, perhaps forwarding old packets rather than current packets.
As a consequence, what the media source sent can be substantially 
delayed
at the receiver with the receiver believing that newly arriving packets
are delayed only by transport delay when the packets may actually be
minutes or hours old.

The most significant change with this text, I think, (apart from 
removing "window") is changing "media source said" to "media source 
sent".  If that's less clear, I can try to put "said" back in, but I 
felt the current wording of "that it is what was said just now" was 
really hard to parse.

Thanks!
Paul

>>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: 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
>>
>>From: "Vincent Roca" <[email-masked]>
>>To: "David Benham" <[email-masked]>; "Paul E. Jones" 
>><[email-masked]>
>>Cc: "Vincent Roca" <[email-masked]>; [email-masked]; 
>>[email-masked]; "The IESG" 
>><[email-masked]>
>>>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
>>>>Follow up question regarding your general comments on sect 8.1 and 
>>>>8.2 which we have not yet addressed in -09 ;
>>>>
>>>>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.
>>>

---

From: Vincent Roca <[email-masked]>
Date: Mon, 13 May 2019 11:47:16 +0200

Hello Paul, all,

> Le 12 mai 2019 à 06:34, Paul E. Jones <[email-masked]> a écrit :
> 
> Vincent,
> 
> Once again, thanks for the feedback.  Please allow me to reply inline and, if you're OK with the text, I can prepare a new revision.
> 
> Actually, after reading that original text, I think it is even misleading to suggest confidentiality is not compromised.  In terms of encryption, that would be true, but in terms of net effect, it would not: without verifying the certificate, an unwanted party could potentially engage in the conference.  I think this would be better text (replacing the entire paragraph):
> 
> Use of mutual DTLS authentication (as required by DTLS-SRTP) ensures that a
> false endpoint or false Media Distributor cannot interact with a legitimate
> Media Distributor or endpoint.  This helps mitigate against denial of service
> attacks wherein a false entity sends a stream of packets that would force
> With respect to whether the DoS mitigation is true or not, I think it is.  If mutual authentication fails, then no media packets would flow at all, thus no wasted time decrypting packets; packets would likely get rejected without inspection.  If mutual authentication succeeds, then the cost isn't at issue here, anyway, since the point of the paragraph is to talk about a side benefit of mutual authentication.  While the specifics are outside the scope of the document, the assumption is that some mechanism is employed to enable checking the validity of certificates.

[VR] Yes for the first aspect.

Concerning DoS mitigation, wether DTLS authentication helps reducing decryption overhead at a receiver
really depends on how authentication is achieved. Looking at RFC 5764 (I imagine this is where DTLS-SRTP
is defined), I read in Section 5.1.2. « Reception », item 3., that decryption and authentication are performed
at the same step. This is in line, although no technical detail is provided, with my comment on authenticated
encryption (see also https://en.wikipedia.org/wiki/Authenticated_encryption). In some cases, decrypting is 
required before checking data authenticity, so authentication won’t be of any help if your goal is to avoid
« spend[ing] time attempting to decrypt », what you're saying. 
RFC 5764, Section 7.4. « Decryption Cost », discusses decryption cost but does not presents authentication
as a solution to mitigate it.

What you’re saying in your answer, above (whether or not mutual authentication fails) is something else.
In section 8.1 we are considering 3rd party attacks, from entities that will never be authenticated.

> Definitely not essential.  I tried to make whole paragraph a little easier to read.  How about this:
> 
> While the Media Distributor can purposely stop forwarding media flows, it
> As a consequence, what the media source sent can be substantially delayed
> The most significant change with this text, I think, (apart from removing "window") is changing "media source said" to "media source sent".  If that's less clear, I can try to put "said" back in, but I felt the current wording of "that it is what was said just now" was really hard to parse.

[VR] okay.

Cheers,

  Vincent

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 14 May 2019 00:21:56 +0000

Vincent,

Please see inline below:

------ Original Message ------
From: "Vincent Roca" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>
Cc: "Vincent Roca" <[email-masked]>; "The IESG" <[email-masked]>; 
"David Benham" <[email-masked]>; 
[email-masked]; 
[email-masked]; [email-masked]
Sent: 5/13/2019 5:47:16 AM
Subject: Re: Secdir last call review of 
draft-ietf-perc-private-media-framework

>>potentially engage in the conference.  I think this would be better 
>>text (replacing the entire paragraph):
>>
>>is.  If mutual authentication fails, then no media packets would flow 
>>at all, thus no wasted time decrypting packets; packets would likely 
>>get rejected without inspection.  If mutual authentication succeeds, 
>>then the cost isn't at issue here, anyway, since the point of the 
>>paragraph is to talk about a side benefit of mutual authentication.  
>>While the specifics are outside the scope of the document, the 
>>assumption is that some mechanism is employed to enable checking the 
>>validity of certificates.
>
>is defined), I read in Section 5.1.2. « Reception », item 3., that 
>decryption and authentication are performed
>at the same step. This is in line, although no technical detail is 
>provided, with my comment on authenticated
>encryption (see also 
>https://en.wikipedia.org/wiki/Authenticated_encryption). In some cases, 
>decrypting is

This paragraph does deal with third parties, so I think it's 
appropriately placed. But clearly the wording still isn't quite right, 
as it's not conveying the intended meaning.  By using mutual 
authentication, a receiving endpoint would know if the sender is or is 
not a valid sender.  There is no need to authenticate the media packets 
received, because the DTLS handshake failed.  Receivers could just 
discard those packets without inspection.  So, the receiver never even 
gets to the point where it's dealing with the authenticated decryption 
of packets.

I revised that paragraph again.  Here is the new text

Use of mutual DTLS authentication (as required by DTLS-SRTP) also helps 
to
prevent a denial-of-service attack by preventing a false endpoint or 
false
Media Distributor from successfully participating as a perceived valid 
media
sender that could otherwise carry out an on-path attack.  When mutual
authentication fails, a receiving endpoint would know that it could 
safely
discard media packets received from the endpoint without inspection.

How is that?

This says nothing about the other forms of attacks, such as a "false" 
endpoint sending bogus media packets to a receiver that carry the IP 
address of a valid sender.  In that case, the receiver would have no way 
of knowing if the packet is valid or not until it goes through the 
authenticated decryption process.  PERC (by its use of HBH 
authentication) would allow the receiver to detect such bogus packets, 
but that is a valid DoS attack vector addressed in prior paragraphs in 
that section.

Paul

---

From: Vincent Roca <[email-masked]>
Date: Wed, 15 May 2019 09:25:53 +0200

Hello Paul,

Okay, I now get it. I was not considering an attacker stupid enough to fail authentication but
who would continue sending trafic with the same identifiers. So I’m okay with your explanations
and new version of the paragraph.

Summary: Ready

Thanks,

  Vincent

> Le 14 mai 2019 à 02:21, Paul E. Jones <[email-masked]> a écrit :
> 
> Vincent,
> 
> Please see inline below:
> 
> To: "Paul E. Jones" <[email-masked] <mailto:[email-masked]>>
> Cc: "Vincent Roca" <[email-masked] <mailto:[email-masked]>>; "The IESG" <[email-masked] <mailto:[email-masked]>>; "David Benham" <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>>> Le 12 mai 2019 à 06:34, Paul E. Jones <[email-masked] <mailto:[email-masked]>> a écrit :
>>> 
>>> Vincent,
>>> 
>> encryption (see also https://en.wikipedia.org/wiki/Authenticated_encryption <https://en.wikipedia.org/wiki/Authenticated_encryption>). In some cases, decrypting is 
> This paragraph does deal with third parties, so I think it's appropriately placed. But clearly the wording still isn't quite right, as it's not conveying the intended meaning.  By using mutual authentication, a receiving endpoint would know if the sender is or is not a valid sender.  There is no need to authenticate the media packets received, because the DTLS handshake failed.  Receivers could just discard those packets without inspection.  So, the receiver never even gets to the point where it's dealing with the authenticated decryption of packets.
> 
> Use of mutual DTLS authentication (as required by DTLS-SRTP) also helps to
> prevent a denial-of-service attack by preventing a false endpoint or false
> Media Distributor from successfully participating as a perceived valid media
> authentication fails, a receiving endpoint would know that it could safely
> This says nothing about the other forms of attacks, such as a "false" endpoint sending bogus media packets to a receiver that carry the IP address of a valid sender.  In that case, the receiver would have no way of knowing if the packet is valid or not until it goes through the authenticated decryption process.  PERC (by its use of HBH authentication) would allow the receiver to detect such bogus packets, but that is a valid DoS attack vector addressed in prior paragraphs in that section.
> 
> Paul
> 
>