Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-sdes-hdr-ext-02

From: Bo Burman <[email-masked]>
Date: Thu, 7 Jan 2016 13:51:40 +0000

So, to summarize the proposed security section changes, what about (only affected parts, note the added SHOULD in the first paragraph):

OLD:
   In RTP sessions where any type of confidentiality protection is
   enabled for RTCP, the SDES item header extensions MUST also be
   protected per default.  This implies that to provide confidentiality,
   users of SRTP need to implement encrypted header extensions per
   [RFC6904].  Commonly, it is expected that the same security level is
   applied to RTCP packets carrying SDES items, and to an RTP header
   extension containing SDES items.  If the security level is different,
   it is important to consider the security properties as the worst in
   each aspect for the different configurations.

   As the SDES items are used by the RTP based application to establish
   relationships between RTP streams or between an RTP stream and
   information about the originating Participant, there SHOULD be strong
   requirements on integrity and source authentication of the header
   extensions.  If not, an attacker can modify the SDES item value to
   create erroneous relationship bindings in the receiving application.

NEW:
   In RTP sessions where any type of confidentiality protection is
   enabled for RTCP, the SDES item header extensions MUST also be
   protected.  This implies that to provide confidentiality, users of
   SRTP need to implement and use encrypted header extensions per
   [RFC6904].  The security level that is applied to RTCP packets
   carrying SDES items SHOULD also be applied to SDES items carried as
   RTP header extensions.  If the security level is chosen to be
   different for an SDES item in RTCP and RTP header extension, it is
   important to motivate the exception, and to consider the security
   properties as the worst in each aspect for the different
   configurations.

   As the SDES items are used by the RTP based application to establish
   relationships between RTP streams or between an RTP stream and
   information about the originating participant, there SHOULD be strong
   integrity protection and source authentication of the header
   extensions.  If not, an attacker can modify the SDES item value to
   create erroneous relationship bindings in the receiving application.

Are those changes acceptable to the WG?

/Bo

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: den 22 december 2015 23:28
> To: Magnus Westerlund
> Cc: [email-masked]; [email-masked]
> Subject: Re: AD Evaluation of draft-ietf-avtext-sdes-hdr-ext-02
> 
> On 14 Dec 2015, at 10:29, Magnus Westerlund wrote:
> 
> > Hi Ben,
> >
> > See below my answer and feedback on your evaluation. I think it is
> > fairly clear that we need to do a new revision prior to the IETF last
> > call.
> >
> > Den 2015-12-12 kl. 05:11, skrev Ben Campbell:
> >> Hi,
> >>
> >> Here is my AD evaluation of draft-ietf-avtext-sdes-hdr-ext-02. I have
> >> a few questions and comments that I would like to resolve prior to
> >> IETF last call, as well as some editorial comments that can be
> >> handled whenever is convenient:
> >>
> >> Thanks!
> >>
> >> Ben.
> >>
> >> === Substantive:
> >>
> >> - 4.2.1, last paragraph:
> >> The guidance about RTP middleboxes seems to apply to header
> >> extensions in general. Is this not already documented somewhere else?
> >
> > Not, what I can remember. It is definitely not in RFC5285, and this
> > should be considered to be added to RFC5285bis draft.
> >
> 
> Okay.
> 
> >>
> >> - 4.2.6, 2nd paragraph: "... issues can be avoid by performing ..."
> >>
> >> Do you mean "... the receiver performing..."?
> >
> > Yes, these are all receiver side actions.
> 
> That's probably obvious, but it wouldn't hurt to be explicit.
> 
> >
> >>
> >> - 5.1:
> >>
> >> Please elaborate on what you mean by sub-space. I don't think RFC
> >> 5285
> >> contemplated this idea. How would IANA indicate that things in this
> >> sub-space have additional rules beyond those of 5285? Or more
> >> concretely, how do we indicate that
> >> urn:ietf:params:rtp-hdrext:sdes:cname is bound by the rules for
> >> urn:ietf:params:rtp-hdrext:sdes?
> >>
> >
> > What I mean is that any URN starting with
> > "urn:ietf:params:rtp-hdrext:sdes" is under these rules. And I think
> > that IANA is already handling different set of rules for different
> > parts of the URN space. The rules for "urn:ietf" is different from the
> > ones for "urn:ietf:params:rtp-hdrext".
> 
> Okay, let me take another approach. RFC 5285 has a set of registration rules for the RTP compact header extension
> registry. This draft says that some entries that contain the string "hdrext:sdes"..." will have additional rules. But this
> doesn't create a new registry, does it? Is there some expectation that a new registrant who wants to register
> "...hdrext:sdes:foo" will even read this draft?
> 
> I'm curious why the group did not define a new table for things like "urn:ietf:params:rtp-hdrext:sdes:foo", with the
> additional registration rules from this draft.
> 
> >
> >> Paragraph 2 says "preferably in a publically available reference." I
> >> think that's a hard requirement in 5285. This seems to relax that--I
> >> assume that is not the intent. Security considerations are also
> >> already
> >> required by 5285 (but there is no mention of privacy considerations.)
> >
> > Yes, you are right, for RTP header extensions RFC5285 do require
> > publicly available specification. I think we might have primarily
> > looked at the rules for SDES items which are according to RFC3550:
> >
> > To facilitate review of requests and to
> > promote shared use of new types among multiple applications, requests
> > for registration of new values must be documented in an RFC or other
> > permanent and readily available reference such as the product of
> > another cooperative standards body (e.g., ITU-T).  Other requests may
> > also be accepted, under the advice of a "designated expert."
> >
> > Which gives some leeway for non public available references which
> > RFC5285 do.
> >
> > I think the easy fix here is to be clear that it must fulfil the rules
> > of RFC5285, and then have this document in addition note the need for
> > 1) being a registered SDES item (implies following the rules in
> > RFC3550 for SDES items), 2) being explicit about privacy
> > considerations and 3) the motivation for timely deliver.
> 
> I agree.
> 
> >
> >>
> >> -6, general:
> >>
> >> The requirements here are pretty abstract. Would it make sense to say
> >> something to the effect of "If you SRTP it you MUST encrypt the RTP
> >> extension header"?
> >
> > In RTP sessions where any type of confidentiality protection is
> > enabled for RTCP, the SDES item header extensions MUST also be
> > protected per default.  This implies that to provide confidentiality,
> > users of SRTP need to implement encrypted header extensions per
> > [RFC6904].
> >
> > I thought the above was basically saying this, with the exception that
> > it gates on encrypting RTCP, rather than using SRTP. And I think you
> > actually want to consider if using just SRTP for integrity protection,
> > i.e. null encryption shall force encryption on the SDES header
> > extension. I am fine to edit this to say that if you confidentiality
> > protect either RTP or RTCP, then you MUST confidentiality protect also
> > this header extension.
> >
> > But, I think for the SRTP parties, if we want to be clearer then we
> > should simpley add "and use" to the second sentence.
> 
> That works for me.
> 
> >
> >>
> >> -6, paragraph 2:
> >> - "In RTP sessions where any type of confidentiality protection is
> >> enabled for RTCP, the SDES item header extensions MUST also be
> >> protected per default. "
> >>
> >> Why “per default”? That tells me that an implementation would, if
> >> not
> >> configured otherwise, protect the header extension if it protected
> >> RTCP.
> >> Do you intend to allow the “configured otherwise” loophole?
> >
> > I am happy to loose the "per default" here. I can't remember a reason
> > for it.
> 
> Okay.
> 
> >
> >>
> >> - "users of SRTP need to implement encrypted header extensions"
> >> Do you mean to say “implementers must also implement” or “users
> >> must
> >> also use”? Or both?
> >
> > The first sentence says you must use it if RTCP is protected. If using
> > SRTP, then this implies that you must implement and use RFC6904 to
> > achieve the normative statement. And as said above, I am happy to
> > clarify that this is really implement and use.
> 
> Okay.
> 
> >
> >>
> >> - "Commonly, it is expected that the same security level is
> >> applied to RTCP packets carrying SDES items, and to an RTP header
> >> extension containing SDES items. "
> >>
> >> The phrase “Commonly, it is expected…” seems to water down the
> >> guidance.
> >> Any reason not to say SHOULD or MUST here?
> >
> > Yes, we can loose the "commonly ..." part. I think SHOULD is good, and
> > and basically ask the ones trying to invoke the exception to motivate
> > themselves.
> 
> Okay.
> 
> >
> >>
> >> - 6, paragraph 3:
> >> - "there SHOULD be strong
> >> requirements on integrity and source authentication"
> >>
> >> What needs to have that strong requirement? The specs for extensions
> >> in
> >> the sub-space? Or does this mean to say that "there SHOULD be strong
> >> integrity protection and source authentication"?
> >
> > The later.
> 
> Okay. If it's not obvious, I propose removing "requirements on"
> 
> [...]