Re: [websec] Minor feedback on draft-ietf-websec-mime-sniff-03

Adam Barth <ietf@adambarth.com> Sun, 15 January 2012 21:06 UTC

Return-Path: <ietf@adambarth.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2DB21F8498 for <websec@ietfa.amsl.com>; Sun, 15 Jan 2012 13:06:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.772
X-Spam-Level:
X-Spam-Status: No, score=-2.772 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U76wrNHu0UoG for <websec@ietfa.amsl.com>; Sun, 15 Jan 2012 13:06:53 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BCA4121F8467 for <websec@ietf.org>; Sun, 15 Jan 2012 13:06:53 -0800 (PST)
Received: by iaae16 with SMTP id e16so8115823iaa.31 for <websec@ietf.org>; Sun, 15 Jan 2012 13:06:53 -0800 (PST)
Received: by 10.50.197.169 with SMTP id iv9mr7362846igc.7.1326661613380; Sun, 15 Jan 2012 13:06:53 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id or2sm17249955igc.5.2012.01.15.13.06.52 (version=SSLv3 cipher=OTHER); Sun, 15 Jan 2012 13:06:52 -0800 (PST)
Received: by iaae16 with SMTP id e16so8115796iaa.31 for <websec@ietf.org>; Sun, 15 Jan 2012 13:06:52 -0800 (PST)
Received: by 10.50.47.229 with SMTP id g5mr10128635ign.23.1326661612116; Sun, 15 Jan 2012 13:06:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.62.139 with HTTP; Sun, 15 Jan 2012 13:06:20 -0800 (PST)
In-Reply-To: <4F133E75.2000204@gmx.de>
References: <20120115195120.GG32205@1wt.eu> <CAJE5ia_gBJ=7DviO5hkmqnXHtC8ptHyKAMieBrFbVV-h9rQo9g@mail.gmail.com> <20120115204154.GH32205@1wt.eu> <CAJE5ia9vPmkMB-NkF-5PRzd2UZcrnSvmVPNYX3XvA80HMeVvEw@mail.gmail.com> <4F133E75.2000204@gmx.de>
From: Adam Barth <ietf@adambarth.com>
Date: Sun, 15 Jan 2012 13:06:20 -0800
Message-ID: <CAJE5ia964ApHCz_B_EKmfEiXQ3xBM6A89RfQynLOe-F1YH6GXQ@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: ian@hixie.ch, websec@ietf.org, Willy Tarreau <w@1wt.eu>
Subject: Re: [websec] Minor feedback on draft-ietf-websec-mime-sniff-03
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Jan 2012 21:06:54 -0000

On Sun, Jan 15, 2012 at 1:00 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2012-01-15 21:53, Adam Barth wrote:
>> On Sun, Jan 15, 2012 at 12:41 PM, Willy Tarreau<w@1wt.eu>  wrote:
>>> On Sun, Jan 15, 2012 at 11:52:38AM -0800, Adam Barth wrote:
>>>> The requirement in the spec is what we intend.  The rule applies only
>>>> to that exact octet sequence.
>>>
>>> But then what are the impacts of not matching the correct content-type ?
>>
>> I'm not sure I understand your question.  Can you explain a scenario
>> in which something happens that causes someone to be sad with the
>> current requirements?
>
> Translating Adam: matching only some specific header field instances is
> intentional, as these are the ones we know misconfigured servers send.
>
> (right?)
>
> It wouldn't hurt if the spec would explain that choice, if it doesn't right
> now.

I believe there's a ticket about adding that description.  We've been
focusing more on the introduction/scope editing at the moment, but
we'll get to this point.

More specifically, this is a workaround for an old (still widely
deployed) version of Apache that used that exact octet sequence to
identify resources for which it didn't know the MIME type.  Apache has
since been changed to omit the Content-Type header in these cases, but
old Apache installs stay around for a very, very long time.  Matching
this exact octet sequence is the minimum injury way of dealing with
this legacy content.

Adam