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

Paul Wouters <paul@nohats.ca> Tue, 14 July 2015 02:02 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7A11A8908; Mon, 13 Jul 2015 19:02:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dydH4WXzt0Y6; Mon, 13 Jul 2015 19:02:26 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DCCF1A8901; Mon, 13 Jul 2015 19:02:26 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mVlTr51zgzpL; Tue, 14 Jul 2015 04:02:24 +0200 (CEST)
Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=UiDUV7qH
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id l1FAwpm1W5bC; Tue, 14 Jul 2015 04:02:23 +0200 (CEST)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 14 Jul 2015 04:02:23 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9BF3680042; Mon, 13 Jul 2015 22:02:22 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1436839342; bh=hbl2kFmOj1HtaZA8FPptKPZ5gZb+V1qI3mOHtaNypaA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=UiDUV7qHUXhTGSWhCd5JerSmq3yrj10rBNsEwIIbdLD1WsJGcVrDGX53+Mgw/fv0I IdZlBRouHRIIBXPjVsh/qWG4cwfS4/uHN4GEl0irNYB9y+sO0WzN4HaUrqgdlgQ9EL 83cigfOZhjw5lUik+l0LOeH386VfMjo8zzWuHMNA=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t6E22LHJ024251; Mon, 13 Jul 2015 22:02:21 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Mon, 13 Jul 2015 22:02:21 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Sean Leonard <dev+ietf@seantek.com>
In-Reply-To: <5D2E6DCF-6AFE-44EA-B367-DE30DDAC7CEF@seantek.com>
Message-ID: <alpine.LFD.2.11.1507132151280.28524@bofh.nohats.ca>
References: <alpine.LFD.2.11.1507011816350.8321@bofh.nohats.ca> <5D2E6DCF-6AFE-44EA-B367-DE30DDAC7CEF@seantek.com>
User-Agent: Alpine 2.11 (LFD 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/queDxdZN-BzXlCXj8Gt2L3Uaha0>
Cc: secdir@ietf.org, The IESG <iesg@ietf.org>, IETF Apps Discuss <apps-discuss@ietf.org>, draft-ietf-appsawg-text-markdown-use-cases.all@tools.ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-appsawg-text-markdown-use-cases (fwd)
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jul 2015 02:02:29 -0000

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