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

[Sean Turner <[e-mail]>]

Murray,

Sergio’s got a fix for the outstanding issue and Barry (ARTART review) agreed:
https://mailarchive.ietf.org/arch/msg/wish/KDfInrIEU9uSSow8Oi_Qvz4BFtw/

Should we ask Sergio to spin a -09 next week so we can get the IETF LC going?

spt

> On Jun 27, 2023, at 10:05, Sergio Garcia Murillo <[e-mail]> wrote:
> 
> 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