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

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 5 Dec 2018 01:12:12 +0000

Please see inline [cue].

-----Original Message-----
From: bfcpbis <[email-masked]> on behalf of Christer Holmberg <[email-masked]>
Date: Monday, December 3, 2018 at 9:17 PM
To: Benjamin Kaduk <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Mary Barnes <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
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
    [email-masked]
    https://www.ietf.org/mailman/listinfo/bfcpbis

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Dec 2018 10:36:25 +0000

Hi,
        
        ....
        
            >>> 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).
            >>
            >> "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." 
            >
           > 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."
        
        Regards,
        
        Christer

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 5 Dec 2018 22:47:45 +0000

-----Original Message-----
From: bfcpbis <[email-masked]> on behalf of Christer Holmberg <[email-masked]>
Date: Wednesday, December 5, 2018 at 7:37 PM
To: Charles Eckel <[email-masked]>, Benjamin Kaduk <[email-masked]>
Cc: Mary Barnes <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [bfcpbis] Benjamin Kaduk's No Objection on draft-ietf-bfcpbis-rfc4583bis-26: (with COMMENT)

    Hi,
            
            ....

    You are right.
    
    So, something like:

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

Cheers,
Charles
            
            Regards,
            
            Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Dec 2018 07:11:14 +0000

The pull request has been updated.

Regards,

Christer

On 06/12/2018, 0.47, "Charles Eckel (eckelcu)" <[email-masked]> wrote:

    -----Original Message-----
    From: bfcpbis <[email-masked]> on behalf of Christer Holmberg <[email-masked]>
    Date: Wednesday, December 5, 2018 at 7:37 PM
    To: Charles Eckel <[email-masked]>, Benjamin Kaduk <[email-masked]>
    Cc: Mary Barnes <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>
    Subject: Re: [bfcpbis] Benjamin Kaduk's No Objection on draft-ietf-bfcpbis-rfc4583bis-26: (with COMMENT)
    
        Hi,
                
                ....

        You are right.
        
        So, something like:

    
    Cheers,
    Charles
                
                Regards,
                
                Christer

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 7 Dec 2018 07:28:47 +0000

Looks good to me, thanks!

Charles

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

    Regards,
    
    Christer

        -----Original Message-----
        From: bfcpbis <[email-masked]> on behalf of Christer Holmberg <[email-masked]>
        Date: Wednesday, December 5, 2018 at 7:37 PM
        To: Charles Eckel <[email-masked]>, Benjamin Kaduk <[email-masked]>
        Cc: Mary Barnes <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>
        Subject: Re: [bfcpbis] Benjamin Kaduk's No Objection on draft-ietf-bfcpbis-rfc4583bis-26: (with COMMENT)
        
            Hi,
                    
                    ....

            You are right.
            
            So, something like:

        
        Cheers,
        Charles
                    
                    Regards,
                    
                    Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Dec 2018 18:40:28 +0000

Adam, can I submit a new version of the draft?

Regards,

Christer

On 07/12/2018, 9.29, "bfcpbis on behalf of Charles Eckel (eckelcu)" <[email-masked] on behalf of [email-masked]> wrote:

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

        Regards,
        
        Christer

            -----Original Message-----
            
                Hi,
                        
                        ....

                You are right.
                
                So, something like:

            
            Cheers,
            Charles
                        
                        Regards,
                        
                        Christer