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

Benjamin Kaduk <kaduk@mit.edu> Sun, 02 December 2018 23:34 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01776130DCE; Sun, 2 Dec 2018 15:34:56 -0800 (PST)
X-Quarantine-ID: <5jQQB5zWlGHU>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jQQB5zWlGHU; Sun, 2 Dec 2018 15:34:53 -0800 (PST)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41918130DBE; Sun, 2 Dec 2018 15:34:52 -0800 (PST)
X-AuditID: 12074425-17fff700000006a4-68-5c046c187573
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id A4.79.01700.91C640C5; Sun, 2 Dec 2018 18:34:50 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.14.7/8.9.2) with ESMTP id wB2NYlPn019815; Sun, 2 Dec 2018 18:34:47 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) �by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wB2NYg9N030359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 2 Dec 2018 18:34:45 -0500
Date: Sun, 02 Dec 2018 17:34:42 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: 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>, "mary.ietf.barnes@gmail.com" <mary.ietf.barnes@gmail.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Message-ID: <20181202233442.GB54918@kduck.kaduk.org>
References: <154046788456.16346.9779422142840687916.idtracker@ietfa.amsl.com> <E35FBC91-7DFF-4EAC-A81F-1F89C5091253@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <E35FBC91-7DFF-4EAC-A81F-1F89C5091253@ericsson.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IR4hTV1pXKYYkxeHuHyeLjwm8sFv/WHWWy uDDzMKNF94q37BYz/kxktvi8fz+zA5vHr69X2Tx2zrrL7rFkyU+mAOYoLpuU1JzMstQifbsE rowZy3wKJgRVbJ+3jL2B8aBNFyMnh4SAicTyLR1MXYxcHEICa5gk1k1azwLhbGCU2L7qPCNI lZDAHSaJNdecQWwWARWJXf/usIPYbEB2Q/dlZhBbRMBM4vrnXrBJzAKrmCQebLoMViQskCCx deouMJsXaN2Wa5eZIIY2M0qs+lYHEReUODnzCQuIzSygJXHj30ugGg4gW1pi+T8OkDCngIPE v5s7GUHCokB7Py8QmMAoMAtJ8ywkzbMQmhcwMq9ilE3JrdLNTczMKU5N1i1OTszLSy3StdDL zSzRS00p3cQICmp2F9UdjHP+eh1iFOBgVOLhdYhniRFiTSwrrsw9xCjJwaQkytu9njlGiC8p P6UyI7E4I76oNCe1+BCjBAezkgiv2xamGCHelMTKqtSifJiUNAeLkjjvH5HH0UIC6Yklqdmp qQWpRTBZGQ4OJQne1wlAewSLUtNTK9Iyc0oQ0kwcnCDDeYCG/3wAtJi3uCAxtzgzHSJ/ilGX Y8+9thnMQix5+XmpUuK8rMlAgwRAijJK8+DmgJKRRPb+mleM4kBvCfO6PwQaxQNMZHCTXgEt YQJakgP2QXFJIkJKqoExyLfv9tFqpwkbJi7qmbk4yrloe5MM51KVeV7/JNydK0uteiJPbOaS 3bDh/3uODfc8Hp1ZXTnx9bup99UOf9qoHrm8bcfSi5cu2wlWTl5h9F3qWOt65mbHj9Mm7WVQ O1rN+iHj5akt1T/Vr9z4JO/bIHFKzldjXnFA278nO/amJLRwb1pzIXSdqhJLcUaioRZzUXEi AKWHjXQhAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/LfrnTZ195NsPRI9ogXrXadDziMQ>
Subject: Re: [bfcpbis] Benjamin Kaduk's No Objection on draft-ietf-bfcpbis-rfc4583bis-26: (with COMMENT)
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Dec 2018 23:34:56 -0000

Hi Christer,

Thanks for the comments and updates! [inline]

On Sun, Dec 02, 2018 at 06:56:03PM +0000, Christer Holmberg wrote:
> Hi Benjamin,
> 
> Thanks for your comments!
> 
> In this reply I will address Benjamin's comments not related to the proto value.
>     
> >    I will go ahead and say that we should discuss the "UDP/TLS/BFCP" naming.
> >    In particular, while I see the previous discussion that there may be
> >    existing deployments out there, why can we not give it the same treatment
> >    as "mstrm", and make the official name "UDP/DTLS/BFCP" while documenting
> >    that you should accept the old name?
>   
> The was addressed already, but just for completeness: the problem is that existing deployments would not accept a new value, so I suggest that we don't change anything.
> 
> ---
> 
> >    We also had a very long discussion about the usage of the term "initial
> >    offer" in the context of draft-ietf-mmusic-sdp-bundle-negotiation; I do not
> >    propose to rehash that discussion, but want to ask whether we should stick
> >    to the established precedent with regard to the use of the term (which,
> >    IIUC, would involve a change to this document).
>   
> This was also addressed: there is text describing what we mean by "initial", and that is the approach we have taken lately when defining offer/answer procedures.
>   
> ---
> 
> >    Section 4
> >    
> >          m=<media> <port> <proto> <fmt> ...
> >    
> >       The media field MUST have a value of "application".
> >    
> >    This is "For BFCP streams, the media field MUST have a value of
> >    application", right?  I might just swap the "This section describes [...]"
> >    paragraph to be after the exerpt from RFC4566 to avoid confusion.
>     
> I will do the swap.
> 
> I don't think we need to add the "For BFCP streams" part, as we already say that the section is for BFCP streams, and with the swap makes it even more clear.
> 
> ---
> 
> >       The fmt (format) list is not applicable to BFCP.  The fmt list of 'm'
> >       lines in the case of any proto field value related to BFCP MUST
> >       contain a single "*" character.  If the the fmt list contains any
> >       other value it is ignored.
> >    
> >    The fmt list is ignored, or the whole m= line (and section)?
>   
> The fmt list.

Okay, I think that's the natural reading of this text, so I don't suggest
any change to it.

> ---
> 
> >    Section 5.1
> >    
> >    The interpretation of the "c-s" value is not mentioned prior to the table
> >    in which it appears, which kind of leaves the reader hanging.  (But I guess
> >    that is still a style matter, so I should have no say on it.)
>  >   
>  >   Table 1 could probably benefit from some discussion of how it is applied,
>  >   since (e.g.) an offer could include both c-only and c-s, and if the answere
>  >   includes s-only, the offerer needs to know which role it is performing.
>  >   It seems like this would be "the offerer proceeds through the following
>  >   table, and if the offer and answer included the values present in the
>  >   current line of the table, that line is a match and determines what role
>  >   the offerer will use".
>  >   (This would be a DISCUSS but I am not convinced that there is a way to
>  >   actually do the wrong thing as an implementation.)
>     
> I agree that the sentence before the table is a little confusing, as it indicates that the table shows which role is taken by the offerer. The table only shows what values the answerer is allowed to use, based on what is offered.
> 
> I suggest the following modified text:
> 
>    "The answerer indicates the role taken by the answerer. The offerer will then take the opposite role. 
>     Table 1 shows the roles that the answerer is allowed to take, based on what roles the offerer has indicated 
>     that it is willing to take."

Ah, yes, that would help the readability; thanks

>  >      Endpoints compliant with [RFC4583] might not include the 'floorctrl'
>  >      attribute in offers and answerer.  If the 'floorctrl' attribute is
>  >      not present the offerer will act as floor control client, and the
>  >      answerer will act as floor control server.
>  >   
>  >   I assume this is going to be backwards compatible, but it might be worth
>  >   explicitly saying so.
>    
> I suggest:
> 
> "...is not present, in order to be interoperable with such endpoints, the offerer wil..."

Sounds good.

> ---
> 
> >    Section 5.4, 5.5
> >    
> >    I'd go with "decimal integer representation" for consistency with the
> >    preceding sections.
> 
> I will add as suggested.
> 
> ---
> 
> >    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.

> ---
>  
> >    Section 8
> >    
> >       When TLS is used with TCP, once the underlying connection is
> >       established, the answerer always acts as the TLS server.  If the TCP
> >       connection is lost, the active endpoint is responsible for re-
> >       establishing the TCP connection.  Unless a new TLS session is
> >       negotiated, subsequent SDP offers and answers will not impact the
> >       previously negotiated TLS roles.
> >    
> >    IMPORTANT: "TLS session" is a term of art, and is in fact nonsensical here.
> >    I think that you mean "TLS connection" or maybe "TLS handshake".
>   
> I will change to "TLS connection".

Thanks!

> ---
>   
> >    Section 10
> >    
> >       If the 'm' line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP' or
> >       'UDP/TLS/BFCP', the offerer and answerer follow the generic
> >       procedures defined in [RFC8122].
> >    
> >    Why is 8122 the reference even for the DLTS values (as opposed to
> >    mmusic-dtls-sdp)?
>   
> 'TCP/DTLS/BFCP' still uses TCP transport.
> 
> ---
>   
> >    Section 10.2
> >    
> >    So the answerer can indicate multiple BFCP versions in the bfcpver
> >    attribute and is not using that attribute to indicate the selected BFCP
> >    version in use?
> 
> Correct.
> 
> Note the following sentence:
> 
> "The BFCP version that will eventually be used will be conveyed with a BFCP-level Hello/HelloAck."
> 
> ---
> 
> >    A ref to RFC 4145 for the 'active' endpoint might be helpful.
>   
> The first occurrence of 'active endpoint' is in Section 8, so I will add a reference there. 

Ah, thanks for checking

> ---
> 
> >    Section 10.3
> >    
> >    The "Note" is indented as if it is part of the list, but it should not be
> >    part of the list.
>   
> Correct. I will fix that.
> 
> ---
> 
> >    Section 10.4
> >    
> >       When an offerer sends an updated offer, in order to modify a
> >    
> >    My knowledge of SDP is rusty (and was sparse to begin with), but can't the
> >    answerer also send a mid-session offer to start renegotiation of various
> >    parameters?  That is, it is not just the offerer that can send an offer
> >    during an existing session.
> 
> Yes, but in that case the endpoints acts as an offerer. The offer/answers roles are per offer/answer transaction (not for the whole session).

Re-reading, I see that this statement is consistent as-is; I'm just
sometimes sensitive to using role-based terminology to identify an endpoint
when the role can change, as the reader can be confused about whether the
old holder or the role or the new holder of the role is being described.

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

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

>     >As Ekr notes in his comment, the potential for privacy considerations
>     >relating to the various identifiers transmitted in the session description
>     >should be discussed.  If the various integer IDs are just local to the
>     >physical premises (even better if they're periodically randomized!), the
>     >impact is going to be fairly limited, but should still be covered.
>     
>     I will cover this when addressing Ekr's comments.

Sure.

> ---
> 
>     > Section 14
>     >
>     >   2.  Authentication (Section 8):
>     >       In last paragraph, made clear that a TCP connection was
>     >       described.
>     >
>     > I'm rather confused at what this is attempting to describe.
>     
> I have to admit I don't understand it either (this is text that was added before I became author), because the corresponding text in RFC 4583 does talk about TCP. My suggestion is to remove the bullet, as it anyway only seems to describe an editorial change.

No objection from here.

Thanks again,

Benjamin