[secdir] Secdir review of draft-ietf-appsawg-text-markdown-use-cases

Paul Wouters <paul@nohats.ca> Wed, 01 July 2015 22:15 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 505821A802E; Wed, 1 Jul 2015 15:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tZ5WWv3xKXDn; Wed, 1 Jul 2015 15:15:16 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84681A1AB3; Wed, 1 Jul 2015 15:15:15 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mMH1D5wRgzCmS; Thu, 2 Jul 2015 00:15:12 +0200 (CEST)
Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=K1/T7vEH
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 yhxViBc7HlGp; Thu, 2 Jul 2015 00:15:11 +0200 (CEST)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 2 Jul 2015 00:15:11 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca []) by bofh.nohats.ca (Postfix) with ESMTP id B5C4C80058; Wed, 1 Jul 2015 18:15:10 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1435788910; bh=zAixQ39BnxEBXWez50UTMK+ZLk6eSbHuOPP1sk8HHhc=; h=Date:From:To:Subject; b=K1/T7vEHNNP2XEMKT3fDDsYhHmnLYx2+yW8qXNVyuqn57dFest1vELL1uIxTSUZpv dgo8qJBrpxp29o2WsFbrZwilPiMT3Vb+zQVrRu9nn69xO6PgnwwxhLdyWe8v0ZFhAl qG3FcwX6zpbQEtmFlUhaUbJ7QkqDAxjqujgG3Uwo=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t61MFAw6008752; Wed, 1 Jul 2015 18:15:10 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Wed, 1 Jul 2015 18:15:10 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-appsawg-text-markdown-use-casas.all@tools.ietf.org
Message-ID: <alpine.LFD.2.11.1507011812310.8321@bofh.nohats.ca>
User-Agent: Alpine 2.11 (LFD 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15
Content-Transfer-Encoding: 8BIT
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/d9nVSswLgaSXr21JP5uJdzSZJO4>
Subject: [secdir] Secdir review of draft-ietf-appsawg-text-markdown-use-cases
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: Wed, 01 Jul 2015 22:15:17 -0000

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.