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

[Roman Danyliw <[e-mail]>]

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