Re: [bfcpbis] Benjamin Kaduk's No Objection on draft-ietf-bfcpbis-rfc4583bis-26: (with COMMENT)

[Christer Holmberg <[e-mail]>]

Hi,

...

    >>>    Section 7
    >>>    
    >>>          Note: When using Interactive Connectivity Establishment (ICE)
    >>>          [RFC8445], TCP/DTLS/BFCP, and UDP/TLS/BFCP, the straight-forward
    >>>          procedures for connection management as UDP/BFCP described above
    >>>          apply.  [...]
    >>>    
    >>>    nit: this sentence as written applies only when all three of ICE,
    >>>    TCP/DTLS/BFCP, and UDP/TLS/BFCP apply (which is nonsensical).  I assume the
    >>>    intended grouping is: (1) ICE is used, and (2) either TCP/DTLS/BFCP or
    >>>    UDP/TLS/BFCP is used.
    >>   
    >> Correct. I will replace "and" with "or".
    >
    >I'm not sure that just replacing the one word is enough of a fix, but I
    >trust you will do the right thing.
    
    I took a second look, and "or" is good :)

---

    >>> Section 12
    >>>
    >>> It's probably worth noting explicitly that the non-(D)TLS proto values
    >>> offer neither integrity protection nor confidentiality protection to the
    >>> BFCP stream.
    >>     
    >> I think the protection of the BFCP streams belong to 4582bis.
    >
    > This is a non-blocking comment, but I think it's appropriate to mention
    > here.	

What about:

"The usage of certain proto values in the SDP offer/answer negotiation will result in a BFCP stream that is not protected by TLS or DTLS. Operators will need to provide integrity protection and confidentiality protection of the BFCP stream using other means."
    
    >>> An attacker able to view the SDP exchanges can determine which media flows
    >>> contain which content, which could exacerbate existing metadata leakage
    >>> channels in some circumstances.
    >>     
    >> I am not sure how that is related to the BFCP SDP negotiation?
    >
    > The premise here (perhaps farfetched) is that the attacker can view the SDP
    > exchange but the actual media flows are secured with (D)TLS and not visible
    > to the attacker.  The (D)TLS flows will leak some information via packet
    > size/timing, perhaps allowing for traffic analysis to determine what sorts
    > of media flows are going where.  The new attributes in the BFCP SDP
    > negotiation can make this sort of traffic analysis more effective.  I would
    > be fairly receptive if you wanted to say that this is not more noteworthy
    > than for normal SDP security considerations, though.
    
In general I agree with you that non-protected SDP attributes can help in traffic analysis, but the BFCP attributes only provide information about the BFCP stream itself - they don't even indicate which media streams will be controlled by BFCP to begin with (that is negotiated on BFCP level).

But, I could add something like:

"The SDP attributes defined in this specification do not add additional security considerations to the generic security considerations for protecting SDP attributes [RFC3264]. The attributes do not reveal information about the content of individual BFCP controlled media streams, nor do they reveal which media streams will be BFCP controlled." 

Regards,

Christer