Re: [AVTCORE] Roman Danyliw's Abstain on draft-ietf-avtcore-rtp-scip-05: (with COMMENT)

[Bernard Aboba <[e-mail]>]

Murray said:

"In my own view, if any part of the payload format needs to be understood
by someone implementing this specification, then the document defining the
payload format has to be a normative reference.  On the other hand, if it's
completely opaque, and for all you know the payload could actually be a
blob of zeroes or random bytes and it wouldn't affect this specification at
all, then it's fine that it's informative."

[BA]  SCIP is similar to other key management frameworks (such as TLS) in
that there is a key management exchange followed by installation of keys,
after which encrypted and integrity protected data is exchanged.  My
understanding is that this is described in the SCIP state machine within
the SCIP-210 which is freely available for download on the Web.

The SCIP layer is provided with the MTU, and generates payloads of
appropriate size that are then fit into the RTP payloads.  Similarly, for
de-packetization, the jitter buffer provides ordered SCIP fragments to the
SCIP layer.  This simplifies the packetization/de-packetization process.

All of this could probably be described in more detail in the document, but
RFC 5716 (EAP-TLS) illustrates the potential downside of carrying that too
far.  EAP-TLS is in principle a very simple protocol in which TLS is
carried over an EAP transport layer described in RFC 3748.  In the
packetization/depacketization process it is not necessary for the EAP
transport to parse TLS at any phase (e.g. before or after key
installation).

However, instead of describing the transport interaction in general terms,
RFC 5716 provided detailed examples as well as text that related to
specific TLS versions.  The result was that much of the document became
obsolete once TLS 1.3 came out and the EMU WG  has had to do extensive
revisions, which might be necessary yet again if and when TLS is upgraded
further. My understanding is that the SCIP WG would like to avoid that kind
of problem.

"Furthermore, the security basis for this document comes from this informative
reference."

[BA] The document does update aspects of RTP security.  For example, it
does not update RFC 3711, which defines the hop-by-hop security properties
of SRTP.  Similarly, the document does not update RTP header extension
security schemes such as RFC 6904 or RFC 9335 (cryptex).

SCIP does add E2E security for the RTP payload, and it is worth noting that
its definition of "E2E" is slightly different from that of similar
proposals such as PERC and SFrame.  So IMHO some more detail with respect
to the security model might avoid confusion down the line.  Having reviewed
SCIP as well as other IETF-developed E2E schemes such as PERC and SFrame, I
believe that the SCIP RTP payload design has some unique advantages that
are worth documenting, and aspects of the SCIP RTP payload specification
(including the SDP negotation scheme) are in the process of being
incorporated into the SFrame RTP payload specification so this document has
been quite influential.

"In either case, once it's a normative reference, I think it's reasonable
to expect that it's available or can be made available to reviewers that
feel they need it to complete their review responsibilities."

[BA] Within the AVTCORE WG, we have required that reviewers been provided
with access to referenced documents, whether the references are normative
or informative. The authors agreed to provide the SCIP documents to
reviewers who have requested it, and to my knowledge they have responded to
all requests.

Similar considerations have also arisen in review of the EVC RTP Payload
format.  In that case, Stephan Wenger has agreed to provide copies of the
ISO EVC specification to reviewers.

"In the 117 meeting just now, there was a claim that an Area Director (I
presume, or maybe some other reviewer) insisted that the missing reference
be made freely available with a deadline measured in hours.  Does anyone
have a copy of that demand?"

[BA] To my knowledge, no AD made a request for the SCIP document, so as to
be able to evaluate whether the spec provided enough detail to understand
the payload format without access to the informative reference.  Early on,
WG participants who requested a copy of the SCIP document experienced some
delays in receiving a response, so that may be what was referred to.  In my
own experience, I requested the document and received a response within a
few days.  I should also say that I had some of the same questions as Roman
before reading the SCIP document.

"I think most of his other points are good, but they don't overcome the
desire to have the key references available to reviewers when the document
is being prepared for publication."

[BA] I don't see any reason to change the requirement for references to be
made available to reviewers upon request.  The IAB has included such a
requirement in multiple liaison documents, including the IETF/IEEE 802
relationship document, RFC 7241.

"So I like the idea discussed in the meeting of preparing a package for
reviewers when this issue might arise, to avoid this problem for future
documents."

[BA] For the EVC RTP payload format, I'm planning to include instructions
on how reviewers can contact Stephan Wenger to obtain a copy of the ISO
spec, which is behind a paywall.



On Wed, Jul 26, 2023 at 5:50 PM Murray S. Kucherawy <[e-mail]>
wrote:

> On Wed, Jul 26, 2023 at 11:18 AM Roman Danyliw via Datatracker <
> [e-mail]> wrote:
>
>> I am abstaining on this document as it is unclear to me how to evaluate
>> this
>> document.  Unlike most of the other recent “RTP Payload Format” document I
>> could find, the text here avoids making a normative reference to a
>> document
>> formally describing a payload. Colloquially, I’m not sure how one can
>> describe
>> the “payload format of _something_” without normatively citing that
>> _something_.
>
>
> In my own view, if any part of the payload format needs to be understood
> by someone implementing this specification, then the document defining the
> payload format has to be a normative reference.  On the other hand, if it's
> completely opaque, and for all you know the payload could actually be a
> blob of zeroes or random bytes and it wouldn't affect this specification at
> all, then it's fine that it's informative.
>
>
>> Furthermore, the security basis for this document comes from this
>> informative reference.
>>
>
> But this is a problem.  If all of the security properties of this document
> are in that one, then I would imagine that one has to be a normative
> reference, and at least the Security ADs have reason to ask questions.
>
> In either case, once it's a normative reference, I think it's reasonable
> to expect that it's available or can be made available to reviewers that
> feel they need it to complete their review responsibilities.  "Reviewers"
> here includes anyone that wants to or is asked to review the document, from
> the working group, through the sponsoring AD, the directorate reviewers,
> and the IESG.  That's not to say we can only produce standards that are
> built atop other open specifications, but it does mean we can't do a
> complete review of something that depends on something else that we can't
> access.
>
> The IESG has been discussing revising guidance around normative external
> references, because this exact issue has come up several times and it's a
> problem each time.  After this week, I'll breathe life into that work again
> now that we have a current case to use as an example.
>
> In the 117 meeting just now, there was a claim that an Area Director (I
> presume, or maybe some other reviewer) insisted that the missing reference
> be made freely available with a deadline measured in hours.  Does anyone
> have a copy of that demand?  That seems like something that deserves
> followup.  I would expect, instead, that a reviewer making such a request
> would say simply "I need that to review this", without imposing any kind of
> deadline, much less an unreasonable one.
>
> There's a separate message from Dan Hanson that holds RFC 8817 as an
> example of where the IESG tolerated this.  I would note that Ben Kaduk (who
> was on the IESG for that document) also had a DISCUSS position that noted
> he "couldn't get my hands on my copy, at least on short notice".  I didn't
> unearth the discussion that followed, but I note that his DISCUSS took over
> six months to clear.  I think most of his other points are good, but they
> don't overcome the desire to have the key references available to reviewers
> when the document is being prepared for publication.
>
> To Spencer's point, the current document shepherd writeup template at
> https://datatracker.ietf.org/doc/shepherdwriteup-template/individual
> includes this question, since last summer:  "List any normative references
> that are not freely available to anyone. Did the community have sufficient
> access to review any such normative references?"
>
> So I like the idea discussed in the meeting of preparing a package for
> reviewers when this issue might arise, to avoid this problem for future
> documents.
>
> Happy to discuss any of this further.
>
> -MSK
>