Last Call Review of draft-ietf-appsawg-xml-mediatypes-09
review-ietf-appsawg-xml-mediatypes-09-secdir-lc-dekok-2014-03-27-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Section 2.2:

   UTF-32 has four potential serializations, of which only two (UTF-32BE
   and UTF-32LE) are given names in in [UNICODE].  Support for the
   various serializations varies widely, and security concerns about
   their use have been raised.

- It would be good to have a reference for the security concerns, or
perhaps a little more discussion.

Section 3

   Other MIME agents will not be XML-aware, and thus cannot know
   anything about the XML encoding declaration.  Not only do they lack
   one of the three sources of information about encoding, they are also
   less likely to be aware of or responsive to this spec.

- it may be useful to discuss how an XML-unware MIME agent will handle
the XML documents.  e.g. do they usually pass the document through
unaltered?  Do they mangle the document, changing it's meaning?  Are
there recommendations for what they should do?

   Some MIME agents, such as proxies and transcoders, both consume and
   produce MIME entities.

- it may be use to have recommendations for what MIME agents should do
(or not) when they want to proxy XML messages, without examining them.

Section 10

   Security considerations will vary by domain of use.  For example, XML
   medical records will have much more stringent privacy and security
   considerations than XML library metadata.  Similarly, use of XML as a
   parameter marshalling syntax necessitates a case by case security
   review.

- it would be good to make recommendations here.  e.g. standards for XML
medical records SHOULD have limitations on which external XML libraries
can be used.  A few paragraphs earlier, this section has the following text:

    Thus,
   the security of any XML document is vitally dependent on all of the
   documents recursively referenced by that document.

- the only way to ensure security of XML records is to control which
documents they reference.  This doesn't matter much for some situations,
where the possible attacks are minor.  It can matter enormously for more
critical situations, like medical records.

   XML may also have some of the same security concerns as plain text.
   Like plain text, XML can contain escape sequences that, when
   displayed, have the potential to change the display processor
   environment in ways that adversely affect subsequent operations.
   Possible effects include, but are not limited to, locking the
   keyboard, changing display parameters so subsequent displayed text is
   unreadable, or even changing display parameters to deliberately
   obscure or distort subsequent displayed material so that its meaning
   is lost or altered.  Display processors SHOULD either filter such
   material from displayed text or else make sure to reset all important
   settings after a given display operation is complete.

- I would suggest changing the SHOULD to a MUST.  The display processor
MUST by default filter such material, or be sure to reset all settings.
 The filter MAY be administratively controlled.  i.e. the user can turn
it off.

   As such, the ability to program keys
   SHOULD be blocked either by filtering or by disabling the ability to
   program keys entirely.

- the same comment as above applies here

   However, even non-
   recursive expansions may cause problems with the finite computing
   resources of computers, if they are performed many times.  For
   example, consider the case where XML-entity A consists of 100 copies
   of XML-entity B, which in turn consists of 100 copies of XML-entity
   C, and so on.

- it would be good to make specific recommendations here.  e.g. XML
processors SHOULD administratively limit the number of XML entities they
will process from one document.  This limitation SHOULD be configurable.
 Where possible, the XML processors may also prompt the end user when
this limit is reached, to see if they should continue processing the
document.