Subject: Re: [avtext] Stephen Farrell's Discuss on draft-ietf-avtext-sdes-hdr-ext-06: (with DISCUSS and COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Wed, 08 Jun 2016 16:16:22 -0500

Hi,

Where did we end up with this? Magnus, any thoughts on Stephen's last mail?

Thanks!

Ben.

On 16 May 2016, at 8:46, Stephen Farrell wrote:

> Hiya,
>
> Sorry for the slow response, was travelling...
>
> On 09/05/16 16:04, Magnus Westerlund wrote:
>> Hi Stephen,
>>
>> Please see inline.
>>
>> Den 2016-05-03 kl. 17:21, skrev Stephen Farrell:
>>> Stephen Farrell has entered the following ballot position for
>>> draft-ietf-avtext-sdes-hdr-ext-06: 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-avtext-sdes-hdr-ext/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>>
>>> I'd like to check if there's a small hole in the
>>> security/privacy properties here. If there is I hope that
>>> a little re-wording will handle it.
>>>
>>> You say: (1) "In RTP sessions where any type of
>>> confidentiality protection is enabled for RTCP, the SDES
>>> item header extensions MUST also be protected." And then
>>> you say: (2) "The security level that is applied to RTCP
>>> packets carrying SDES items SHOULD also be applied to
>>> SDES items carried as RTP header extensions."
>>>
>>> My concerns are that the SHOULD in (2) isn't really well
>>> motivated (for me) - you just seem to say that someone
>>> who doesn't follow the SHOULD has to say why, but I don't
>>> think that's likely a run-time concept.
>>
>> So there are two aspects of this. The first is that protection really
>> should be applied on matching level, if there are exceptions to this,
>> then this is not a run-time decision for it. The run-time property here
>> that makes this a bit more complicated, is that we have a much more
>> limited set of algorithms for RTP header extension confidentiality
>> protection, than we have for RTP and RTCP packets in general. Thus,
>> there are a risk that there is not possible to find a matching security
>> level. And we fairly often can end up in situations where the same
>> security level is not available. However, this later case is handled by
>> the general formulation of "security level" which gives some leeway for
>> not having the same algorithms.
>
> Ok, if this is down to crypto algorithms or modes of operation of
> crypto algorithms, then would something like "MUST use commensurate
> strength algorithms and SHOULD use the same cryptographic
> primitives (algorithms, modes)" work?
>
>>
>>
>>  Secondly, (1)
>>> doesn't say that the new stuff has to be protected in the
>>> same way, e.g. with the same endpoints having the keys,
>>> and not e.g. where the RTCP data has e2e protection but
>>> the new header field just has hop-by-hop protection.
>>
>> No, and for basic SRTP and existing specifications we only have
>> mechanisms dealing with protection to the next RTP hop, that are
>> trusted.
>
> I think that'd be worth explaining a bit in the document,
> as it wasn't at all clear to me. Would it be clear to folks
> who know loads about RTP/RTCP but less about security? If
> not, then I'd say explaining it would be good.
>
> The distinctions you are getting into become relevant in the
>> PERC context, where it might not exist matching capabilities between
>> hop-by-hop and end-to-end. If I correctly remember where the WGs
>> discussion has ended up, we will be able to protected the SDES data
>> end-to-end in the RTP header extension, but not in RTCP.
>>
>> I will note that the CNAME SDES item, when correctly generated is not
>> privacy sensitive and also needed in the intermediate node to know which
>> RTP streams that share synchronization context.
>>
>> I will also note that in my view having the same security level will
>> mean that you will have to provide the same treatment in a PERC context
>> in respect to end-to-end vs hop-by-hop.
>>
>>>
>>> Are my concerns justified? (If not, that's fine you'll
>>> tell me and we're done:-)
>>
>> Yes, I think they are justified.
>>
>>>
>>> If these are justified concerns, I think we can easily
>>> get around them by (a) closing that potential loophole in
>>> (1) and (b) s/SHOULD/MUST/ in (2) or else (c) better
>>> specify an exception to the SHOULD that makes sense at
>>> coding time or at run time.
>>
>> I am fine with changing this to a MUST. I note that this might require a
>> bit of an upgrade of the header extension protection mechanism to fulfil
>> the MUST, but I don't see the lack of algorithm a valid exception to the
>> SHOULD either.
>
> See if the text suggestion above works.
>
> Cheers,
> S.
>
> PS: Your responses to the comments below are just fine too.
>
>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>>
>>> - So this one confused me for a bit but I was thinking
>>> about RFC4568 - shame about that acronym collision;-)
>>> It'd have helped this reader to say that this is not
>>> about sending keys in header fields:-) But I'm probably
>>> not the intended reader, so it's fine that you didn't.
>>
>> I agree that the collision is confusing, but I think we are fairly clear
>> in the first sentences in the Introduction and abstract:
>>
>> This specification defines an RTP header extension [RFC3550][RFC5285]
>>    that can carry RTCP source description (SDES) items.  Normally the
>>    SDES items are carried in their own RTCP packet type [RFC3550].
>>
>> I intended to ignore this comment.
>>
>>>
>>> - I wonder if confidentiality protection of these header
>>> fields is likely? Is that more or less likely to be
>>> deployed than some security for RTCP? If there's a
>>> significant difference then I think that ought be called
>>> out. Just pointing at rfc6904 doesn't seem entirely
>>> sufficient to me if nobody ever does it.
>>
>> I don't really know about the implementation status for RFC6904. I found
>> that Google just a couple of days ago committed to chronium a patch for
>> RFC6904 support.
>>
>>>
>>> - Has someone done an analysis of the privacy
>>> implications of moving values from one context (RTCP) to
>>> another (RTP) over the range of likely deployments? Note:
>>> I'm not asserting that there is a significant privacy
>>> exposure here, I don't know if there is or not. So I'm
>>> just asking if folks have thought about that and e.g.
>>> whether or not some data exposed in this header field
>>> could allow easier re-identification or correlation or
>>> some similar and possibly subtle privacy issue.
>>
>> So RTP/RTCP really is one protocol.
>>
>> However, I don't think there has been any deeper analytics of this. What
>> I believe this can reveal to a party watching the packet fly by, is
>> identifying the RTP/RTCP implementation.
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> ----------------------------------------------------------------------
>> Services, Media and Network features, Ericsson Research EAB/TXM
>> ----------------------------------------------------------------------
>> Ericsson AB                 | Phone  +46 10 7148287
>> Färögatan 6                 | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden | mailto: [email-masked]
>> ----------------------------------------------------------------------
>>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 10 Jun 2016 11:48:50 +0200

> Where did we end up with this? Magnus, any thoughts on Stephen's last mail?

Yes, Stephen's suggestion works for us. We are submitting a new version 
now. Please check that these do resolve the issue.

Cheers

Magnus

-- 

Magnus Westerlund