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

[Paul Wouters <[e-mail]>]

On Mon, 13 Jul 2015, Sean Leonard wrote:

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

Perfect.

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

No that's fine. If you already had that discussion, and this is the
outcome of that, that is good enough for me. Although perhaps an
additional warning in the Security Section could be used to clarify
this a little more.

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

Sounds good too.

Paul