Re: Should we say anything on security?

On Tue, Sep 11, 2012 at 8:25 PM, Uche Ogbuji <uche@ogbuji.net> wrote:

> MicroXML happens to close some of the more notorious security holes
> associated with XML: the billion laughs attack from external entity
> processing and CDATA injection.  Is it worth making a statement in the spec
> that we believe its simplifications also improve security in dealing with
> MicroXML on networks?
>

I think that's worth saying in the intro as part of describing the value
proposition of MicroXML. We can also say that another factor that may make
it more suitable for protocols is that it allows you to follow the
long-standing IETF tradition of being liberal in what you accept.

The idea of a MicroXML RFC has come up and in that case we'd have to make
> some sort of statement on security, anyway.
>

For an RFC style Security Considerations section the following seem
relevant:

RFC 3552: Guidelines for Writing RFC Text on Security Considerations

and the Security Considerations sections of

RFC 1874: SGML Media Types
RFC 3023: XML Media Types
RFC 3470: BCP for XML within IETF protocols
RFC 3628: UTF-8

I would suggest the following points:

1. We use UTF-8 so the security considerations of RFC 3628 apply

2. We should say something about the applicability of XML Digital
Signatures to MicroXML.
a) You need to use a MicroXML parser not an XML parser to construct the XML
DSig data model, because newlines in attribute values aren't normalized in
MicroXML
b) The XML C14N of a MicroXML document will be XML but may not be MicroXML,
because MicroXML requires > to be quoted in attribute values.  This
typically doesn't matter, because the only thing you usually do to the C14N
output is feed it into a hash algorithm

3. I think it's worth pointing out that you can construct documents that
cause even a streaming parser to use memory proportional to the size of the
input by using large attribute values, large attribute/element names, large
numbers of attributes or deep element nesting. So in resource-constrained
security-sensitive situations parsers may want to put hard limits on such
things to reduce the possibility of DoS attacks.

RFC 1874 has this:

SGML entities contain information to be parsed and processed by the
> recipient's SGML system. Those entities may contain and such systems may
> permit explicit system level commands to be execute while processing the
> data. To the extent that an SGML system will execute arbitrary command
> strings recipients of SGML entities may be at risk.


and RFC3023 says essentially the same thing.  I don't find this
particularly helpful.

James