Re: [Perc] Roman Danyliw's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)

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

Roman,

Thanks for the reply.  I made the change as you suggested below and 
published a new version:
https://tools.ietf.org/html/draft-ietf-perc-private-media-framework-12

Let me know if there are any other changes you feel should be made.

Thanks!
Paul

------ Original Message ------
From: "Roman Danyliw" <[e-mail]>
To: "Paul E. Jones" <[e-mail]>; "The IESG" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>; 
"[e-mail]" 
<[e-mail]>; "[e-mail]" 
<[e-mail]>; "[e-mail]" <[e-mail]>
Sent: 6/5/2019 4:41:16 PM
Subject: RE: [Perc] Roman Danyliw's Discuss on 
draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)

>Hi Paul!
>
>
>
>Sorry for the delay!
>
>
>
>From: iesg [mailto:[e-mail]] On Behalf Of Paul E. Jones
>Sent: Thursday, May 16, 2019 9:14 PM
>To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
>Cc:[e-mail]; 
>[e-mail]; [e-mail]; 
>[e-mail]
>Subject: Re: [Perc] Roman Danyliw's Discuss on 
>draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)
>
>
>
>Roman,
>
>
>
>Thanks for reviewing the text.  Please see comments below:
>
>
>
>>----------------------------------------------------------------------
>>
>>DISCUSS:
>>
>>----------------------------------------------------------------------
>>
>>
>>
>>I support Magnus’s DISCUSS about the need to further discuss the 
>>impact of a
>>
>>compromised/rogue end-point. In addition to the impersonation of 
>>others in the
>>
>>conference, I am wondering about the impact (perhaps a DoS?) of rogue 
>>client
>>
>>flooding the conference with EKT Key updates.
>>
>>
>>
>ACK; will continue to work with Magnus on this.
>
>
>
>[Roman] The new language in -11 addressed my concerns.  Thank you for 
>this new, robust text.
>
>
>
>>----------------------------------------------------------------------
>>
>>COMMENT:
>>
>>----------------------------------------------------------------------
>>
>>
>>
>>(1) Section 1. Per “Virtualized public cloud environments have been 
>>viewed as
>>
>>less secure since resources are not always physically controlled by 
>>those who
>>
>>use them and since there are usually several ports open to the public. 
>>This
>>
>>document aims to improve security so as to lower the barrier to taking
>>
>>advantage of those environments”, I stumbled over these sentences. 
>>Improve
>>
>>security relative to what – self hosted environments? Is the security 
>>target
>>
>>have fewer open ports and secure in the face of an adversary with 
>>physical
>>
>>access to the system? The latter seems like a very high bar and the
>>
>>corresponding Security Considerations doesn’t seem to rise to that.
>>
>
>
>Improved security relative to traditional switching conferencing 
>platforms wherein there is a media function running on those 
>virtualized hardware platforms holding the keys to encrypt and decrypt 
>media.
>
>
>
>The number of open ports really doesn't make much difference, but I 
>think whoever crafted that text originally meant to emphasize how 
>porous those platforms can be. I think we could remove the bit about 
>the open ports and it would still convey the intended meaning. Want me 
>to do that?
>
>
>
>[Roman] I get the idea of being porous, but yes, could you please 
>remove the this language about ports.
>
>
>
>With PERC, an adversary could do anything with the middlebox (even if 
>running in that cloud environment) and the confidentiality of the 
>conference would not be compromised. (PERC does not thwart DOS attacks, 
>but that's not an objective.)
>
>
>
>How would you suggest we make that clearer?
>
>
>
>[Roman] My concern with clauses that suggest resistant to an adversary 
>with physical access to the system is discussing attacks things need to 
>be resistant to attacks where full memory can be dumped or inline 
>hardware can be inserted.  However, put in more limited context as you 
>state, I see what you mean.  No concern now.  Thanks.
>
>
>>(2) Section 6.1. “Endpoints have to retain old keys for a period of 
>>time to
>>
>>ensure they can properly decrypt late-arriving or out-of-order 
>>packets” seems
>>
>>to restate what is stated in 4.5.2 using RFC2119 language. Here 
>>“endpoints
>>
>>have to retain”. In Section 4.5.2, “endpoints SHOULD retain”. Which 
>>one is
>>
>>correct?
>>
>
>
>"have to" wasn't intended to be normative. The purpose of the sentence 
>was really to remind readers that there might be quite a few keys held 
>at any given point in time, especially when the conference is rekeyed. 
>But, I can see that wasn't clear. How about this text?
>
>
>
>Complicating key management is the fact that the KEK can change and, 
>when
>
>it does, the Endpoints generate new SRTP master keys that are 
>associated with
>
>a new EKT SPI. Endpoints might retain old keys for a period of time to
>
>ensure they can properly decrypt late-arriving or out-of-order packets, 
>which
>
>means the number of keys held during that period of time might 
>substantially
>
>more.
>
>
>
>[Roman]  Looks good.  Thank you for this new language.
>
>
>
>>(3) Section 8.1. Per “Off-path attackers could try connecting to 
>>different PERC
>>
>>entities and send specifically crafted packets”, could you be more 
>>specific on
>>
>>the threat. Is this something different than any service being exposed 
>>on the
>>
>>Internet?
>>
>
>
>This is saying that it's not possible for an attacker to send packets 
>of any form that could be misconstrued to be valid media that needs to 
>be forwarded or rendered since packets are authenticated before 
>consumption. (It doesn't prevent a DoS attack, but that's covered in 
>subsequent paragraphs.) But, I can see how this might not make sense. I 
>think a few more words are needed. How is this?
>
>
>
>Off-path attackers could try connecting to different PERC entities to
>send specifically crafted packets with an aim of forcing the receiver 
>to
>forward or render bogus media packets.  Endpoints and Media 
>Distributors
>
>mitigate such an attack by performing hop-by-hop authentication and
>
>discarding packets that fail authentication.
>
>
>
>[Roman]  That’s more precise.  Thank you for this new language.
>
>
>
>>(4) Editorial Nits:
>>
>>** Section 3. Typo. s/the the/the/
>>
>>
>>
>
>
>Oh! An easy one! :)
>
>
>
>I made those changes above to my local copy, but I'm happy to make 
>additional changes as you suggest if the text still isn't clear.
>
>
>
>Thanks!
>
>Paul
>
>
>