Re: [clue] AD evaluation: draft-ietf-clue-framework-22

[Ron Even <[e-mail]>]

Hi Alissa,
See inline
Roni

On Fri, Jul 3, 2015 at 9:28 PM, Alissa Cooper <[e-mail]> wrote:

> I have reviewed this document in preparation for IETF LC and I have some
> comments and questions I'd like to see resolved before issuing the last
> call. I've also listed some nits further below that should be resolved in
> the next revision of the document.
>
> Overall, the amount of complexity that this framework supports in terms of
> the number of configuration choices that can be provided and consumed is
> daunting. I know the WG is already well down the path towards finishing
> this off so I'm not suggesting changes in this regard, but I do think folks
> should be prepared for questions about the trade-off between flexibility
> and implementability that may arise during IETF LC or IESG evaluation.
>
> Substantive comments and questions:
>
> = Section 3 =
> Why are these definitions not necessarily consistent with the definitions
> in RFC 7262 (e.g., Endpoint)? Why not just rely on the definitions in that
> document for terms being re-used? I know there was a conclusion that strict
> alignment with the taxonomy doc was not necessary, but it seems like at
> least the CLUE docs should be internally consistent.
>

RE: We had a definition document
https://www.ietf.org/archive/id/draft-wenger-clue-definitions-02.txt that
tried to capture the terminology for telepresence systems, we decided that
it should not be a separte document and moved the content to the
framework, the other documents should be consistent with it


>
> = Section 7.1.1.10 =
> I think this section (and to some extent the one that follows) require a
> more thorough explanation to justify how it is that sending a lot of
> detailed information about the people involved in a telepresence session
> actually helps the endpoints decide how to arrange the media in the
> session. I understand that some (limited) information is useful for display
> purposes, but this section provides really broad leeway for endpoints to
> send a lot of information about individual participants without a
> thoroughgoing justification of how policies are built that act on such
> detailed information.
>

RE:  By Christian

>
> On the other hand, there are some data fields I would have expected to
> possibly be useful for these kinds of policies, like device type or room
> type or even device name, but it's not clear how endpoints are supposed to
> communicate those, if at all (stuff them into an xCard somewhow?). What is
> the story as far as those kinds of attributes go?
>
> = Section 7.2.1.1 =
> Just because the syntax of the MaxCaptures definition theoretically allows
> for it to be set to <=1 does not mean that semantic should necessarily be
> allowed in the protocol. I don't understand the case where sending <=1
> should be considered valid -- why have an MCC with zero captures in it? It
> seems like =1 and <=N where N>1 are the only valid values here.
>
RE: By Christian

>
> = Section 15 =
>
RE: wii respond later

> "Thus, it is RECOMMENDED that an MCU
>    implementing the protocols necessary to support CLUE, follow the
>    security recommendations specified in the conference control
>    protocol documents."
>
> The specific documents need to be listed here, assuming RFC 4579 is not
> the only one to be mentioned.
>
> "Thus
>    the security mechanisms recommended for SIP [RFC3261], including
>    user authentication and authorization, SHOULD be followed."
>
> Given that implementations will need to be updated to support CLUE, what
> is the rationale for having user authentication and authorization be
> optional? What are the cases where allowing an unauthenticated or
> unauthorized participant to join a telepresence session would be considered
> acceptable?
>
> "In
>    addition, the media is based on RTP and thus existing RTP security
>    mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported.
>    Media security is also discussed in [I-D.ietf-clue-signaling] and
>    [I-D.ietf-clue-rtp-mapping]."
>
> I think it's worth pointing out in this document that DTLS/SRTP is
> required to use for CLUE-controlled m-lines. Also, I just did a quick skim
> of draft-ietf-clue-rtp-mapping and didn't see anything in there about media
> security.
>
> "A separate data channel is established to transport the CLUE
>    protocol messages. The contents of the CLUE protocol messages are
>    based on information introduced in this document.  The CLUE data
>    model [I-D.ietf-clue-data-model-schema] defines through an XML
>    schema the syntax to be used. Some of the information which could
>    possibly introduce privacy concerns is the xCard information as
>    described in section 7.1.1.11.  In addition, the (text)
>    description field in the Media Capture attribute (section 7.1.1.7)
>    could possibly reveal sensitive information or specific
>    identities. The same would be true for the descriptions in the
>    Capture Scene (section 7.3.1) and Capture Scene View (7.3.2)
>    attributes.   One other important consideration for the
>    information in the xCard as well as the description field in the
>    Media Capture and Capture Scene View attributes is that while the
>    endpoints involved in the session have been authenticated, there
>    is no assurance that the information in the xCard or description
>    fields is authentic.  Thus, this information MUST NOT be used to
>    make any authorization decisions."
>
> I don't think it's enough to point out that sensitive data can be sent
> back and forth with CLUE and that it shouldn't be used for authorization
> decisions. Is there some guidance that can be given about minimizing the
> amount and sensitivity of data to be sent? Are there certain xCard fields
> that endpoints should avoid sending? Some of this is obviously dependent on
> context and whether the participants in a conference know this information
> about each other already, but it's still worth mentioning how to mitigate
> the risks of sharing more data or more sensitive data than is necessary for
> the purposes of supporting a telepresence session. This might imply
> additional text in 7.1.1.10 as well.
>
> "Thus, it MUST be possible for the endpoints to establish
>    a channel which is secure against both message recovery and
>    message modification. Further details on this are provided in the
>    CLUE data channel solution document."
>
> There are no details about how the data channel is secured in
> draft-ietf-clue-datachannel (which should be cited here if it's going to be
> referenced). Nor are the details in draft-ietf-rtcweb-data-channel, but
> rather they are in draft-ietf-rtcweb-security-arch and
> draft-ietf-rtcweb-security.
>
> Furthermore, the details provided in draft-ietf-rtcweb-security-arch and
> draft-ietf-rtcweb-security explain the situation for rtcweb, where the
> endpoints rely on identity providers to authenticate each others'
> identities. IdPs are not specifically included in the CLUE architecture
> and, as noted above, the SIP authentication mechanisms are optional -- so
> how is it that the CLUE data channel is actually secured against an active
> MITM?
>
>
> Nits:
> There are a bunch of uses of normative MAY in this document that don't
> really fit the RFC 2119 usage of the term (i.e., are not actually protocol
> options). I've pointed them out below along with other nits.
>
> = Section 3 =
> "The spatial region represented by a Capture
>    Scene MAY correspond to a real region in physical space, such as a
>    room."
>
> I don't think normative language is necessary here. s/MAY/may/
>
> s/[RFC4353] like Mixer/[RFC4353]-like Mixer/
>
> = Section 4 =
> s/it should be stressed that its use in an implementation/it should be
> stressed that their use in an implementation/
>
> = Section 5 =
> "Also, the Consumer
>    MAY use the information provided to tailor the SDP it is going to
>    send during any following SIP offer/answer exchange, and its
>    reaction to SDP it receives in that step."
>
> I don't think normative language is necessary here. s/MAY/may/
>
> "For example, if both sides decide to upgrade the call from a single
> screen to a
>    multi-screen call and more bandwidth is required for the additional
>    video channels compared to what was previously negotiated using
>    offer/answer, a new O/A exchange is REQUIRED."
>
> I don't think normative language is necessary here since this is just an
> example. s/REQUIRED/required/
>
> = Secton 7.1.1.4 =
> s/High dynamic/Highly dynamic/
>
> = Section 7.1.1.11 =
> Not everyone considers "chairman" to be a gender-neutral term. You might
> want to consider "chair" and "vice-chair" instead.
>
> In general it's hard for me to believe that there is much of an
> interoperability gain from specifying titles in this level of detail,
> rather than just allowing advertisers to specify all of their own -- is
> there some compelling need to specify this set of values initially?
>
> = Section 7.1.1.12 =
> s/no assumptions regarding relative important/no assumptions regarding
> relative importance/
>
> = Section 7.1.1.13 =
> s/the video Capture MAY contain speech to text information/the video
> Capture may contain speech to text information/
>
> = Section 7.2.1.1 =
> s/MaxCaptures MAY be set to one/MaxCaptures may be set to one/
>
> = Section 10 =
> s/Optimized implementations MAY speed up the reaction to the
>    offer/answer exchange/Optimized implementations may speed up the
> reaction to the
>    offer/answer exchange/
>
> = Section 10.1 =
> s/if the Consumer is an MCU, it MAY choose to receive/if the Consumer is
> an MCU, it may choose to receive/
>
> s/user choice (for instance, selection of a new layout) MAY result/user
> choice (for instance, selection of a new layout) may result
>
> _______________________________________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue
>