Re: [AVTCORE] Design choice comments on draft-jones-avtcore-private-media-framework-00

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

Magnus,

>>  The requirements are in the separate requirements document. This
>>  document was intended to present one possible direction, but I
>>  appreciate there are different views.
>
>Yes, but the document is called a framework. I did notice that you
>updated the requirements document to create an explicit requirement on
>keeping the SSRC. I fail to see why that occurred, it didn't appear to
>be motivated at all.

I assume you might be referring to PM-06.  That has been there for a 
while, existing as PM-10 in the -00 draft.  The reason is just that we 
need an end-to-end cryptographic context.  Appreciating that this could 
be made to be less SRTP-centric (e.g., something we could implement with 
something like Aero), perhaps this might be a better PM-06?

PM-06: A cryptographic context suitable for enabling end-to-end 
authenticated encryption MUST be defined. Note that in SRTP, the 
cryptographic context includes the SSRC, sequence number and rollover 
counter (ROC).

>>>>   The intention was the RTP header extensions and RTCP could
>>>>  optionally be
>>>>   encrypted using the SRTP keys exchanged as they are today. This 
>>>>would
>>>>   be done hop-by-hop. This does not provide for end-to-end privacy, 
>>>>of
>>>>   course. That fits with the goals we've stated in the requirements
>>>>   document. We're not trying to hide the fact that two people
>>>>   communicated, for example, but we do not want to disclose what is 
>>>>being
>>>>   communicated.
>>>>
>>>>   If there is truly a need to encrypt end-to-end such that middle 
>>>>boxes
>>>>   cannot gain access to some RTP header extensions or some RTCP data
>>>>   fields, I would assert we need to define a way to allow some 
>>>>header
>>>>   extensions and some RTCP header fields to be visible hop-by-hop. 
>>>>We do
>>>>   want to enable middleboxes to be able to collect and use RTCP
>>>>   statistics, for example. We also want to allow them to have access 
>>>>to
>>>>   any header extension that help facilitate packet forwarding and
>>>>  processing.
>>>
>>>  I fully agree that there MUST be possibility to have both RTP header
>>>  extensions as well as many type of RTCP packets to be only protected 
>>>hop
>>>  by hop. The core of my comment is rather that the solution appear to
>>>  need to take into account the likely need for end-to-end protection 
>>>of
>>>  other RTP/RTCP fields and actively discuss in its security
>>>  considerations the privacy risk from some existing RTP/RTCP protocol
>>>  elements, specifically the RTCP SDES items.
>>
>>  You're right that we did not consider a need for end-to-end security 
>>of
>>  RTCP or header extensions. Our objective was to ensure that media was
>>  secured. The need to secure RTCP end-to-end would present certain
>>  challenges for aggregating RTCP information. If we support encryption
>>  end-to-end of portions, that might be OK, but we didn't have a need 
>>for
>>  that. You mentioned having location information in RTP or RTCP. Are
>>  there truly requirements for that? Is that for the benefit of 
>>emergency
>>  services to get location of a caller while moving?
>
>I want people to think about this issues, an not immediately dismiss 
>the
>idea just because it might look hard and they can't think of an
>immediate need for it.

We did not dismiss it for reasons of difficulty.  Rather, we were only 
focused on ensuring end-to-end media privacy (i.e., voice and video 
content) and did not have a a requirement for ensuring that control 
information be encrypted end-to-end.  That said, it is more challenging 
when there is a need for intermediary to act on some parts of the 
control information and not other parts.


>>>  I fully understand that there is need to enable multiple technical
>>>  solutions for verifying that identity, however if the intention is 
>>>to
>>>  provide a framework for solving this issue, the requirement on parts
>>>  that are outside of this WGs main expertise, namely RTP must still 
>>>be
>>>  discussed.
>>
>>  Agreed, but should it be discussed in the framework or in a separate
>>  draft? I expect before this work is done that there would be one or
>>  more drafts covering the signaling, identity, etc. issues.
>
>I think there need to be something high level that discuss the trust
>model and what entities that involved and what requirements exists on
>the different entities and their interactions. Then one point to
>specific pieces for how to fulfil these requirements.
>
>This is touching on an issue that I think we need to discuss. Is really
>AVTCORE the right WG for this? I have been away so I missed the earlier
>steps, but from my personal perspective we have a lot of data that
>AVTCORE has big issues gathering critical mass on security related 
>topics.

All good points.  I think it's worth the group's time to discuss the 
problem we're trying to solve at a high level and fight the right home 
for it if avtcore is not the most appropriate place.

Finding security experts on any vertical topic is always a challenge and 
not unique to avtcore.  In an ideal world, there would be folks who are 
"dedicated" to security matters in all areas, but that's difficult to do 
since people have other work and already don't have enough time in the 
day.  Still, I agree we need an appropriate review of the work.


>Okay, I hope that the AVTCORE agenda discussion that you have requested
>will focus on the most important high level bits. I think you need to
>consider to actually send the questions you intended to discuss to the
>WG mailing list ahead of time so people can prepare.

I'll try to do that, but the way things have been going in my work 
day-to-day, it might be quite late this week or early next week (e.g., 
Sunday night).

Paul