Re: [websec] Strict-Transport-Security syntax redux

Adam Barth <ietf@adambarth.com> Sat, 29 October 2011 08:22 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 62E2221F84CC for <websec@ietfa.amsl.com>; Sat, 29 Oct 2011 01:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.428
X-Spam-Level:
X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.549, 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 GME3RxKPcRqW for <websec@ietfa.amsl.com>; Sat, 29 Oct 2011 01:22:04 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BEA0021F8888 for <websec@ietf.org>; Sat, 29 Oct 2011 01:22:04 -0700 (PDT)
Received: by iabn5 with SMTP id n5so6220220iab.31 for <websec@ietf.org>; Sat, 29 Oct 2011 01:22:04 -0700 (PDT)
Received: by 10.42.144.198 with SMTP id c6mr8882691icv.45.1319876524357; Sat, 29 Oct 2011 01:22:04 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id fu10sm6087951igc.6.2011.10.29.01.22.03 (version=SSLv3 cipher=OTHER); Sat, 29 Oct 2011 01:22:03 -0700 (PDT)
Received: by iabn5 with SMTP id n5so6220201iab.31 for <websec@ietf.org>; Sat, 29 Oct 2011 01:22:03 -0700 (PDT)
Received: by 10.231.6.129 with SMTP id 1mr2073339ibz.31.1319876523136; Sat, 29 Oct 2011 01:22:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.205.195 with HTTP; Sat, 29 Oct 2011 01:21:32 -0700 (PDT)
In-Reply-To: <4EABB712.5000002@gmx.de>
References: <4EAB66B3.4090404@KingsMountain.com> <CAJE5ia8SkXpwymXVgbjE7YejeNwoMsieUMMgHyBUbi5w2508iQ@mail.gmail.com> <4EABB440.1030906@gmx.de> <CAJE5ia8rDCDVsK1WjGZO6tBfvFnpmeLDRzhg-F_xBipSHa9tYg@mail.gmail.com> <4EABB712.5000002@gmx.de>
From: Adam Barth <ietf@adambarth.com>
Date: Sat, 29 Oct 2011 01:21:32 -0700
Message-ID: <CAJE5ia-oOiBb2FTj_8Hxg9dyy=Oq8Y++VvLeQS=q2CUR1edHDQ@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] Strict-Transport-Security syntax redux
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: Sat, 29 Oct 2011 08:22:05 -0000

On Sat, Oct 29, 2011 at 1:19 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2011-10-29 10:10, Adam Barth wrote:
>>
>> On Sat, Oct 29, 2011 at 1:07 AM, Julian Reschke<julian.reschke@gmx.de>
>>  wrote:
>>>
>>> On 2011-10-29 05:08, Adam Barth wrote:
>>>>
>>>> ...
>>>>>
>>>>> Except for RFC6265, which in the algorithm for parsing "Max-Age=", it
>>>>> algorithmically provides for ignoring a value that doesn't match the
>>>>> effective value ABNF of..
>>>>>
>>>>>  ["-"]*DIGIT
>>>>>
>>>>> ..which would catch the max-age="1" case, but doesn't seem to
>>>>> explicitly
>>>>> address..
>>>>>
>>>>>  max-age=
>>>>
>>>> That's handled by some more general processing rules in the spec.  The
>>>> net result is that it's ignored.
>>>>
>>>>> But in any case, perhaps (additional) browser implementor folk could
>>>>> chime
>>>>> in here -- do we really need to address such detail-level issues (both
>>>>> of
>>>>> the examples above and below) in the syntax/grammar we specify in specs
>>>>> such
>>>>> as these? Or is the new ABNF proposed in the original message in this
>>>>> thread
>>>>> sufficient?
>>>>
>>>> Generally, we prefer to be instructed exactly how to behave for every
>>>> possible input (even illegal ones).  There's a long history of
>>>> quoted-string not being implemented correctly by browsers.  I spec
>>>> this as just splitting the string on ; and then processing each
>>>> substring separately, ignoring bogus/future ones.  I know Julian has a
>>>> dream that all HTTP headers will be parsed the same, but quoted-string
>>>> is sufficiently ill-defined w.r.t. error handling that I prefer to
>>>> avoid it.
>>>> ...
>>>
>>> - when discussing generic parsing, we need to distinguish between legacy
>>> cases like cookies, and new headers, where we can do better
>>>
>>> - standardizing handling of broken headers is one thing (and in general I
>>> prefer not to), but that doesn't mean that when defining a new header
>>> field
>>> we shouldn't minimize the things a sender can get wrong; if we know that
>>> some recipients will accept both token and quoted-string anyway, then it
>>> seems like a good thing to simply allow them both, reducing the number of
>>> special-cases in parsing
>>>
>>> - not sure what you mean by "ill-defined w.r.t. error handling"; it's
>>> defined just like most other syntax elements in HTTP -- is there
>>> something
>>> *specific* to quoted-string you have in mind?
>>
>> Most of HTTP is ill-defined w.r.t. error handling.  We muddle through
>> with reverse engineering.
>> ...
>
> It's not ill-defined, but undefined (by design) - see
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/186>.
>
> What I was trying to understand whether there's something special with
> respect to quoted-string?

Quoted string is particularly bad because it's hard to know what to do
with unbalanced quotation marks.

Anyway, I'm resigned to lose this argument in this forum.  It just
means we'll need to clean up the mess later in another forum.

Adam