[secdir] SECDIR review of draft-ietf-appsawg-multipart-form-data-08

Chris Lonvick <lonvick.ietf@gmail.com> Wed, 01 April 2015 17:15 UTC

Return-Path: <lonvick.ietf@gmail.com>
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 2C9AB1A0056; Wed, 1 Apr 2015 10:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9oTv1Y2FRINf; Wed, 1 Apr 2015 10:15:00 -0700 (PDT)
Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E281A0055; Wed, 1 Apr 2015 10:15:00 -0700 (PDT)
Received: by pddn5 with SMTP id n5so61138610pdd.2; Wed, 01 Apr 2015 10:14:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=vzBps80pwypn9vfYBMFed/6bWXTRGC/sdPp2MRF2SM4=; b=JFFLPKLWqLF1rP48gA+BH2rMbSH2xQqUCyMhf99bTz2ufoEYnm8QdL+bQPleA15GsN U6RfxHKIBa5+KMIV4DjMH6HbT5kMReGP7rCjP5iPtFQKmSITjP3YAZsIr414eByvaQhe D9b5hXN8qDMblNs3hhU2E7yOZylF+bIi7EWVbsTMx2tVCCUjkMVv+1XcGJBT7CGryocs bXsiycfbn4vCvBDpXrWwJPgm3dPEvWYpz0zwGsiFLs0UPwwWfdp5J1emvXNLHyx3JFVR /cPX0HH3igTkP9uw0VzEqsNEn+yr8zsgrPmO6wi2DJpmXNKgr1sQU0ob28a9Y+7PVq1d Bi8A==
X-Received: by with SMTP id z1mr79796720pbw.112.1427908499705; Wed, 01 Apr 2015 10:14:59 -0700 (PDT)
Received: from [] (172-3-137-150.lightspeed.sntcca.sbcglobal.net. []) by mx.google.com with ESMTPSA id je11sm2669502pbd.65.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2015 10:14:59 -0700 (PDT)
Message-ID: <551C2791.7090206@gmail.com>
Date: Wed, 01 Apr 2015 10:14:57 -0700
From: Chris Lonvick <lonvick.ietf@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org
Content-Type: multipart/alternative; boundary="------------040602060508070505010801"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/DxKtLLYs2UPdbJL4x7NzkPaOZ_A>
Subject: [secdir] SECDIR review of draft-ietf-appsawg-multipart-form-data-08
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: <http://www.ietf.org/mail-archive/web/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 Apr 2015 17:15:02 -0000


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

I only got a chance to skim through the document but the Security
Considerations section looks to be consistent with RFC 2388, which it
intends to replace.

I would suggest placing the last paragraph of the Security Considerations
section at the top of the section.  That paragraph seems to be the most
comprehensive in these considerations, and the other paragraphs seem to
augment and give specific details.  It just seems to me that it would
provide a better flow to reading that section.

Also, I'm just not sure that I'm following the second paragraph of
Appendix B:
    More problematic is the ambiguity introduced because implementations
    did not follow [RFC2388  <https://tools.ietf.org/html/rfc2388>] because it used "may" instead of "MUST" when
    specifying encoding of field names, and for other unknown reasons, so
    now, parsers need to be more complex for fuzzy matching against the
    possible outputs of various encoding methods.
Please correct me if I'm off base here, but it sounds like the ambiguity
set in because implementations WERE following RFC 2388 by making
choices on their own (due to the "may"s) rather than being directed to
make uniform choices which would have been mandated if that RFC had used

Finally, I usually advocate giving directions to implementers about what
to do if they find implementations using the older, outdated spec.  As
an example, what should a receiver do if it gets a ContentType that does
not have a "boundary" parameter?  However, as I'm not really familiar
with this technology, and as the document says there are many ways to
do all of this, then I'm not sure that could or should be discussed.  If
it is something that would better define behavior then I would suggest
providing some guidance here.

Best regards,