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

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 03 May 2016 08:21:15 -0700

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

Are my concerns justified? (If not, that's fine you'll
tell me and we're done:-) 

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.

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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 9 May 2016 17:04:43 +0200

Hi Stephen,

Please see inline.

Den 2016-05-03 kl. 17:21, skrev Stephen Farrell:
> 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.

  Secondly, (1)
> 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. 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.

> tell me and we're done:-)

Yes, I think they are justified.

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

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.

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

> 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: Stephen Farrell <[email-masked]>
Date: Mon, 16 May 2016 14:46:49 +0100

Hiya,

Sorry for the slow response, was travelling...

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

> 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
> the MUST, but I don't see the lack of algorithm a valid exception to the

See if the text suggestion above works.

Cheers,
S.

PS: Your responses to the comments below are just fine too.