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

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

    Hi,
            
            ....
            
                >>>>> 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?
                >>>>
                >>>> 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.
    
    You are right.
    
    So, something like:
    
            "The generic security considerations associated with SDP attributes are defined in [RFC3264]. While the 
              defined in this specification do not reveal information about the content of individual BFCP controlled 
              media streams, they do reveal which media streams will be BFCP controlled."

Yes, except s/While the defined/While those defined

Cheers,
Charles
            
            Regards,
            
            Christer    
    
    _______________________________________________
    bfcpbis mailing list
    bfcpbis@ietf.org
    https://www.ietf.org/mailman/listinfo/bfcpbis