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


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

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?


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


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

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