Re: [Wish] Publication has been requested for draft-ietf-wish-whip-08

[Sergio Garcia Murillo <[e-mail]>]

Hi Murray.

I have create issues with your feedback on the github tracker and generate
changes for most of them:

https://github.com/wish-wg/webrtc-http-ingest-protocol/issues?q=is%3Aissue+is%3Aclosed+label%3Aad-review

On Thu, Jun 8, 2023 at 4:28 PM Murray S. Kucherawy <[e-mail]>
wrote:

> Sorry I missed this earlier.
>
> On Thu, May 11, 2023 at 1:50 AM Sergio Garcia Murillo <
> [e-mail]> wrote:
>
>>
>>
>>
>>> * There are lots of SHOULDs that could benefit from some explanation of
>>> when one might not do what the SHOULD says (or do what the SHOULD NOT
>>> says).  Since you're giving implementers a choice here, some advice about
>>> that choice would be good to include.  Or maybe some of these SHOULDs
>>> really ought to be MUSTs?  Same goes for RECOMMENDED.  For instance in
>>> Section 4, you have "The SDP offer SHOULD use the "sendonly"
>>> attribute.  Why?  Or why would I not?  What if I don't?
>>>
>>
>> In WHIP we are reusing the WebRTC/SDP/RTP specifications, and defining
>> how those specs are used to establish a streaming session. As SDP O/A is a
>> negotiation between the client and the server, there are some options that
>> while there are not the correct ones according to our intended usage (like
>> sending "sendonly" as direction on the SDP offer), they are not "illegal"
>> in the WebRTC/SDP specs. For example, if you build a WHIP client on a
>> browser, the default direction on the offer will be "sndrcv", and the
>> server should be ready to accept it. The MUST is on the server side that
>> has to answer with a "recvonly" direction always. So in this particular
>> case, the direction sent by the client is a bit irrelevant, but the proper
>> value semantically is "sendonly", that's why it is a SHOULD and not a MUST.
>>
>
> OK, I think you might consider adding text to this effect.  If you're
> going to make it a normative almost-requirement, it's good to explain to
> implementers why, and/or what happens if they don't.
>

I have been reviewing the recommended language usage and added further
clarifications on the reason of the recommendation on many of them:

https://github.com/wish-wg/webrtc-http-ingest-protocol/commit/c499dbab5ad5ea651c65a818d7e303c314a4e048



>
>> * This is a pretty thin Security Considerations section.  Is that really
>>> all there is?  Shouldn't we at least say something like "As this protocol
>>> is built entirely atop SDP and (things), the security considerations of
>>> those protocols apply here as well."?  It's pretty unusual to claim
>>> (expressly or by omission) that a new protocol has absolutely no security
>>> concerns.
>>>
>>
>> Definitely the section would require a rewrite, however the intent would
>> be the same. We are "just" specifying the usage of well known protocols
>> (webrtc, SDP, https,.. ) so we are not introducing any new attack surface
>> that was not already covered in those. The only point that could be new to
>> this protocol is explaining the security of the rest api calls with the
>> bearer token, any suggestion on how this could be rewritten?
>>
>
> I think the suggestion I made would suffice: At a minimum, be explicit
> that you're importing the security consideration of the layer below.
> Adding some text about the security issue you just identified would also be
> helpful.
>

This was perfect timing as  Sandro Gauci made a presentation about the WHIP
surface attack  and security concerns during the last CommCon UK conference
last week.

I have added his feedback to the security section and also added more
details of the imported security considerations from the lower layers:

https://github.com/wish-wg/webrtc-http-ingest-protocol/commit/6196413f6d12798c9ee6557ce3a2dcfa0ebef16a#diff-6ca9ae63875a605dbaf6d8e45c08b5945951d62135ae0661065b7fe9ebb04d84R405




>
>>
>>> * Sections 6.3 and 6.4 confuse me, though this is possibly just my
>>> inexperience with URN namespaces talking.  It looks like you're creating a
>>> registry for IANA to manage, but doing it completely outside of the pattern
>>> RFC 8126 describes.  Given the reference to RFC 3553, I'm guessing this is
>>> somewhat normal, though I wonder why RFC 2434 wasn't used.  Is that all
>>> correct?
>>>
>>
>> I don't have much knowledge about the urn ietf namespace, but the ones on
>> the RFC 2434 don't seem appropriate to me and the only one that seems to be
>> active at IANA are the "urn:ietf:params:" namespaces specified in rfc3553:
>> https://www.iana.org/assignments/params/params.xhtml#urn-subnamespaces
>>
>> I used the SCIM registry as an example when writing the WHIP registry ,
>> but it is also used by the rtp header extension registry. Is there anyone
>> that we could ask to confirm if this is ok?
>>
>
> Let me ask a couple of people and get back to you.
>
>
This is the only pending topic from your review, I will comment on the
email from Barry.

Best regards
Sergio