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

["Charles Eckel (eckelcu)" <[e-mail]>]

Looks good to me, thanks!

Charles

-----Original Message-----
From: Christer Holmberg <[e-mail]>
Date: Friday, December 7, 2018 at 4:12 PM
To: Charles Eckel <[e-mail]>, Benjamin Kaduk <[e-mail]>
Cc: Mary Barnes <[e-mail]>, "[e-mail]" <[e-mail]>, The IESG <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [bfcpbis] Benjamin Kaduk's No Objection on draft-ietf-bfcpbis-rfc4583bis-26: (with COMMENT)

    The pull request has been updated.
    
    Regards,
    
    Christer
    
    
    On 06/12/2018, 0.47, "Charles Eckel (eckelcu)" <[e-mail]> wrote:
    
        -----Original Message-----
        From: bfcpbis <[e-mail]> on behalf of Christer Holmberg <[e-mail]>
        Date: Wednesday, December 5, 2018 at 7:37 PM
        To: Charles Eckel <[e-mail]>, Benjamin Kaduk <[e-mail]>
        Cc: Mary Barnes <[e-mail]>, "[e-mail]" <[e-mail]>, The IESG <[e-mail]>, "[e-mail]" <[e-mail]>
        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
            [e-mail]
            https://www.ietf.org/mailman/listinfo/bfcpbis