Re: [secdir] Secdir review of draft-ietf-appsawg-text-markdown-use-cases (fwd)

[Sean Leonard <[e-mail]>]

Thank you. Responses below.

On Jul 1, 2015, at 3:17 PM, Paul Wouters <[e-mail]> wrote:

> 
> Sorry for the typo :)
> 
> Paul
> 
> ---------- Forwarded message ----------
> Date: Wed, 1 Jul 2015 18:15:10
> From: Paul Wouters <[e-mail]>
> To: [e-mail], [e-mail],
>    [e-mail]
> Subject: Secdir review of draft-ietf-appsawg-text-markdown-use-cases
> 
> 
> 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.

It does describe some actual code.

I can change the text to:
{{
The variant identifier itself should be stored in a resource with a name including the term “variant” (possibly including other decorations to avoid namespace collisions).
}}

How is that?

> 
> 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.

The purpose of this section was to suggest that if, for example, “pandoc” is the recipient’s preferred Markdown processor, and the recipient receives Markdown content in some other variant that pandoc supports (let’s say original Markdown), then the recipient can send the Markdown through pandoc with the markdown_strict option; the recipient does not need to have or use Gruber’s original Markdown.pl implementation to get at what the sender wanted. It is not necessary for the recipient to have millions of different Markdown implementations, only that it has one (or a small handful) of implementations that are good enough for the purpose.

There was significant discussion on apps-discuss (see around October 2014?) about how it is bad for the sender to be able to specify specific processing instructions, e.g., command-line commands or options that get sent directly to a command interpreter. So, that approach was jettisoned at that time.

The text in Section 2.4 says:

This strategy is to **translate** the processing instructions **inferred from** the [parameters] into a sequence of commands in the **local convention**, storing those commands in a batch script […] that are **appropriate (and safe) for the local system**.


(Emphasis mine.) I think those emphasized parts capture the point that whatever code gets executed has to be appropriate and safe for the local system.

I am happy to reword this paragraph somehow, but if that is seen as necessary, I would appreciate a counterproposal.



A parenthetical note: Section 2.5 of text-markdown-use-cases (“Process the Markdown”) is a bit ambiguous. The point is to process the Markdown before the recipient sees it. Thus if you are composing an e-mail in Markdown, the point would be that your sending MUA (or an intermediary) would convert it to HTML before recipients receive the e-mail. However, your Markdown-aware sending MUA could save drafts in Markdown before the message is sent.

Proposed text:
{{
2.5. Process the Markdown In Advance

This strategy is to process the Markdown into the formal markup, before a recipient receives it, which eliminates ambiguities. Once the Markdown is processed into (for example) valid XHTML, an application can save a file as "doc.xhtml" or can send MIME content as application/xhtml+xml with no further loss of metadata. While unambiguous, this process may not be reversible.
}}

Thanks,

Sean