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

Please see inline [cue].

-----Original Message-----
From: bfcpbis <bfcpbis-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com>
Date: Monday, December 3, 2018 at 9:17 PM
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Mary Barnes <mary.ietf.barnes@gmail.com>, The IESG <iesg@ietf.org>, "draft-ietf-bfcpbis-rfc4583bis@ietf.org" <draft-ietf-bfcpbis-rfc4583bis@ietf.org>, "bfcpbis-chairs@ietf.org" <bfcpbis-chairs@ietf.org>
Subject: Re: [bfcpbis] Benjamin Kaduk's No Objection on draft-ietf-bfcpbis-rfc4583bis-26: (with COMMENT)

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

[cue] I don't think I agree with this last part. The info in SDP does indicate which media streams will be controlled using BFCP. For example,

   m=application 50000 TCP/TLS/BFCP *
   a=setup:actpass
   a=connection:new
   a=fingerprint:sha-256 \
        19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \
        BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
   a=floorctrl:c-only s-only
   a=confid:4321
   a=userid:1234
   a=floorid:1 mstrm:10
   a=floorid:2 mstrm:11
   a=bfcpver:1 2
   m=audio 50002 RTP/AVP 0
   a=label:10
   m=video 50004 RTP/AVP 31
   a=label:11

The combination of floorid/mstrm and label attributes indicate that the corresponding audio and video m-lines are to be controlled via BFCP.

Cheers,
Charles

    Regards,

    Christer

    _______________________________________________
    bfcpbis mailing list
    bfcpbis@ietf.org
    https://www.ietf.org/mailman/listinfo/bfcpbis