Last Call Review of draft-ietf-appsawg-text-markdown-use-cases-02

Request Review of draft-ietf-appsawg-text-markdown-use-cases
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-07-03
Requested 2015-06-25
Authors Sean Leonard
Draft last updated 2015-07-02
Completed reviews Genart Last Call review of -02 by Tom Taylor (diff)
Secdir Last Call review of -02 by Paul Wouters (diff)
Opsdir Last Call review of -02 by Dan Romascanu (diff)
Assignment Reviewer Paul Wouters 
State Completed
Review review-ietf-appsawg-text-markdown-use-cases-02-secdir-lc-wouters-2015-07-02
Reviewed rev. 02 (document currently at 07)
Review result Has Issues
Review completed: 2015-07-02


I have reviewed this document as part of the security directorate's
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 comment.

This document describes use cases and sometimes existing deployed code
on handling "markdown" text. As such, the document introduces no new
security considerations, and the Security Considerations section points
to other documents that further document the respective markdown
variants and their own security considerations.

Recommendation:  Ready with Issues

I wanted to point out two use cases (or existing deployed code?)
that uses some features that might be considered a security issue.

2.1 talks about filesystem "extended attributes" and suggests to add a
    resource named "variant". This name might be a little too generic to
    only apply to markdown and might cause a name spaec collision that
    could potentially be a security risk. If this is a use case without
    deployed code, I would recommend renaming this resource to something
    more specific, eg "markdown-varient". If it describes actual code,
    then I guess that ship has sailed.

2.4 talks about MIME aware clients saving a "batch script" to disk for
    later execution. These kind of "autorun" or "preview" features are
    a security nightmare, so here too I would hope this has not yet been
    coded. And if not, to reconsider not supporting such a feature.