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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 15 May 2019 18:52:36 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-perc-private-media-framework-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/

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

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

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

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

(4) Editorial Nits:
** Section 3. Typo. s/the the/the/

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 17 May 2019 01:14:21 +0000

Roman,

ACK; will continue to work with Magnus on this.

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?

>have to retain”.  In Section 4.5.2, “endpoints SHOULD retain”.  Which one is

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

>the threat.  Is this something different than any service being exposed on the

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.

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