Last Call Review of draft-ietf-appsawg-xml-mediatypes-09
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.
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.
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.
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
- 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:
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
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