[clue] Benjamin Kaduk's Discuss on draft-ietf-clue-signaling-14: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-clue-signaling-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 11.2 of the IANA considerations lists an actual OID value to use
for the "sip.clue" media feature tag, but the IANA last call review
indicates that the decimal value for sip.clue will be assigned at
registration, so it is incorrect to claim that it will be 1.3.6.1.8.4.29.
Squatting on the next available codepoint like this is quite risky and I
really want to discourage this practice.  We had a lot of trouble in TLS
recently with *three* different extensions attempting to use the same
codepoint, which was not fun to resolve.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please consider using the RFC 8174 version of the BCP 14 boilerplate.

Section 3

   The "sip.clue" media feature tag SIP [RFC3840] indicates support for
   CLUE in SIP [RFC3261] calls.

nit: I think there's a missing word or three here; maybe "for SIP"?

Section 4.3

   The restrictions on CLUE-controlled media always apply to "m=" lines
   in an SDP offer or answer, even if negotiation of the data channel in
   [...]

I'm not entirely sure I understand what "the restrictions" are, here.
Unless this is supposed to just be the general requirements for how they
are (not) sent?

Section 4.4.1.1

   Each <encID> (in encodingIDList) in a CLUE ADVERTISEMENT message
   SHOULD represent an Encoding defined in SDP; the specific Encoding
   referenced is a CLUE-controlled "m=" line in the most recent SDP sent
                                                    ^^^^^^^^^^^^^^^
   by the sender of the ADVERTISEMENT message with a label value
   corresponding to the text content of the <encID>.

Is this "most recent SDP Offer/Answer"?
(Similarly in the following paragraph.)
I'm also not sure why these are SHOULD- instead of MUST-level requirements,
modulo the non-atomicity mentioned in the final paragraph of the section.

Section 4.5.1

[I will leave it to Adam to check that the "initial offer" terminology is
being used in the consensus manner, since I haven't been tracking what
manner that is.]

Section 4.5.2.2

(Also in 4.4.1.1) Am I reading this correctly that with the initial offer,
we are talking about negotiating media lines with labels that correspond to
CLUE Encoding names that have not yet been present in any CLUE messages
(that is, we're doing it "blind")?

Section 4.5.4.2

   group then the call is now CLUE-enabled; negotiation of the data
   channel and subsequently the CLUE protocol begin.

nit: begins

Section 4.5.4.4

   o  The CLUE protocol enters an unrecoverable error state as defined
      in Section 6. of [I-D.ietf-clue-protocol], either the 'MP-
      TERMINATED' state for the Media Provider or 'MC-TERMINATED' for
      the Media Consumer.

The MP-TERMINATED and MC-TERMINATED states do not seem to exist in the -17
of the protocol document.  (I'm assuming this is essentially editorial
in nature and doesn't need to be part of the DISCUSS section.)

Section 5.1

   The primary implication of this is that a device may receive an SDP
   with a CLUE Encoding for which it does not yet have Capture [...]

presumably this is "SDP Offer/Answer" as well?

   A device with the CLUE Participant state machine in the ACTIVE state
   MAY choose not to move from ESTABLISHED to ADV (Media Provider state
   machine) or from ESTABLISHED to WAIT FOR CONF RESPONSE (Media
   Consumer state machine) based on the SDP state.  [...]

Is this "choose not to move", "choose to not move", or "chose whether or
not to move"?

Section 5.2

                    : an implementation MUST NOT send a specific CLUE
   Capture Encoding unless its most recent SDP exchange contains an
   active media channel for that Encoding AND the far end has sent a
   CLUE CONFIGURE message specifying a valid Capture for that Encoding.

nit: "far end" is perhaps a bit informal; "peer" or "MC" might be
alternatives.
I guess technically this also doesn't require that he CONFIGURE parsed
correctly and was accepted, which is arguably a bug.

Section 8

   With the successful initial SDP Offer/Answer exchange complete Alice
   and Bob are also free to negotiate the CLUE data channel.  This is
   illustrated as CLUE DATA CHANNEL ESTABLISHED.

   Once the data channel is established CLUE protocol negotiation
   begins.  In this case Bob chose to be the DTLS client (sending
   a=active in his SDP answer) and hence is the CLUE Channel Initiator
   and sends a CLUE OPTIONS message describing his version support.  On
   receiving that message Alice sends her corresponding CLUE OPTIONS
   RESPONSE.

My understanding was that the DTLS connection was a prerequisite for
setting up the CLUE data channel (so I would have been less confused if the
note about DTLS client was in the first paragraph).

There are some instances of "CLUE channel" in this section that might be
better as "CLUE data channel".

Is it normal for the mid of the CLUE data channel to be changing around in
the various SDP snippets shown in these examples?

Section 12

   This attack can be prevented by ensuring that the media recipient
   intends to receive the media packets.  As such all CLUE-capable
   devices MUST support key negotiation and receiver intent assurance
   via DTLS-SRTP [RFC5763] on CLUE-controlled RTP "m=" lines.  All CLUE-
   controlled RTP "m" lines must be secured and implemented using
   mechanisms such as SRTP [RFC3711].  CLUE implementations MAY choose
   not to require the use of SRTP to secure legacy (non-CLUE-controlled)
   media for backwards compatibility with older SIP clients that are
   incapable of supporting it.

Should these normative requirements be placed somewhere in the main body of
this (or some other) document in addition to their necessity being
described in the security considerations here?

Section 14.2

Should-ietf-rtcweb-data-channel be a normative reference?  (It seems like
it should be so at least in draft-ietf-clue-datachannel, which is not on
this week's telechat.)  I think that RFC 3840 should be normative here,
though, since you have to use it to enable CLUE.  There's probably others,
though I'd be inclined to consider at least the core SIP and SDP specs as
"basic specifications" (per
https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/)
that do not need to be normative.