Subject: [Perc] Follow-up on John's suggested requirement additions

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Oct 2015 14:59:03 +0000

Folks,

John suggested the addition of several new requirements.  I captured 
notes on what was proposed and comments received.  If I missed anything 
important, please bring that to my attention.

These didn't seem to receive any objections.  Shall we add these?

A. The e2e replay protection MUST be provided for the whole duration of 
the conference.
B. The solution SHALL make it possible for a receiving endpoint to 
detect if the MDD delays packets for significantly longer than the 
network delay.
C. Endpoint joining the conference MUST authenticate the MDD.
D. The e2e layer SHALL NOT be dependent on the hbh layer. [Shall we use 
the word "layer"?]
E. It shall in the future be possible to use e.g. hbh DTLS for increased 
confidentiality and privacy.
F. The end-to-end keying material shall be stored securely in the 
endpoint and usage restricted so that it is infeasible to extracted or 
used the key for anything else that EKT.

We had several that received more comments.  They are...

G. It SHALL be infeasible for the MDD to spoof the identity of a packet 
sender, including making packets from two different sending endpoints 
look like they originated from a single sending endpoint.

John clarified that by "identity" he meant "the unique e2e identity, the 
last design meeting decided the unique
e2e identity should be SSRC (but SSRC is not a good term to use as it is 
also a RTP field that will be changed by some MDDs)."

Given that, I would generally say this is acceptable since the MDD does 
not have the keys used by the endpoint.  That said, EKR asked whether we 
need to worry about collusion between an endpoint and the MDD.  I don't 
think we can do anything about that, though, since we are building a 
system that places trust in the endpoint.  So, shall we add this?

Another was:

H. The MDD MUST authenticate and authorize the endpoints joining the 
conference, ensuring that the endpoint has been invited to the 
conference.

People did not seem favorable to adding this one.  Shall we abandon it?

Another was:

J. The service provider shall be able to enforce end-to-end security 
using a specific key.
("I" was skipped on purpose to avoid confusion with 1 and l.)

This caused some confusion, so John offered this alternative wording for 
"C":

"The solution SHALL enforce end-end security using a specific key"

I'm unclear about what that means.  Does that mean a shared key, as 
we've discussed doing?  If so, sure.  Is there some other meaning?

Another was:

K. It MUST be possible for the KMF to an function within a participating 
endpoint

That was not proposed wording presented before, but was a question 
raised an answered.  Shall we add that?

Lastly, John said this regarding the current requirement #4:

M. The requirement should be expanded to make clear that parties that 
are not trusted must also not be able to use the end-to-end keying 
material in any other way than expected.
("L" was skipped on purpose to avoid confusion with 1 and I.)

The text in #4 already says end-to-end keys shall not be generated or 
accessible by anything that is not trusted.  Do we really need this?  
I'm missing what would change in the requirement.

If we can get closure on at least some of these, I'll try to prepare a 
draft to publish at the start of the meeting.

Lastly, when I converted the requirements to markdown, I found numbering 
requirements without the "PM-" prefix is simpler and cleaner.  If that's 
OK, I'll just number them without the "PM-" prefix.

Paul