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

Adam Barth <ietf@adambarth.com> Sat, 29 October 2011 18:51 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 77AC221F85D1 for <websec@ietfa.amsl.com>; Sat, 29 Oct 2011 11:51:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.481
X-Spam-Level:
X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.496, 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 3bQA3SpgQLnR for <websec@ietfa.amsl.com>; Sat, 29 Oct 2011 11:51:40 -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 AC5DF21F84CB for <websec@ietf.org>; Sat, 29 Oct 2011 11:51:40 -0700 (PDT)
Received: by iabn5 with SMTP id n5so6766186iab.31 for <websec@ietf.org>; Sat, 29 Oct 2011 11:51:40 -0700 (PDT)
Received: by 10.231.8.143 with SMTP id h15mr2649048ibh.94.1319914300311; Sat, 29 Oct 2011 11:51:40 -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 e2sm18196105ibe.0.2011.10.29.11.51.38 (version=SSLv3 cipher=OTHER); Sat, 29 Oct 2011 11:51:39 -0700 (PDT)
Received: by iabn5 with SMTP id n5so6766155iab.31 for <websec@ietf.org>; Sat, 29 Oct 2011 11:51:38 -0700 (PDT)
Received: by 10.231.6.129 with SMTP id 1mr2770089ibz.31.1319914298606; Sat, 29 Oct 2011 11:51:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.205.195 with HTTP; Sat, 29 Oct 2011 11:51:07 -0700 (PDT)
In-Reply-To: <CAJE5ia-hBNmYuhjWXsjke_QWT9pU_3N0XeGw+xo1ArMqSWa7TA@mail.gmail.com>
References: <4EAB66B3.4090404@KingsMountain.com> <CAJE5ia8SkXpwymXVgbjE7YejeNwoMsieUMMgHyBUbi5w2508iQ@mail.gmail.com> <4EABB440.1030906@gmx.de> <CAJE5ia8rDCDVsK1WjGZO6tBfvFnpmeLDRzhg-F_xBipSHa9tYg@mail.gmail.com> <4EABB712.5000002@gmx.de> <CAJE5ia-oOiBb2FTj_8Hxg9dyy=Oq8Y++VvLeQS=q2CUR1edHDQ@mail.gmail.com> <4EABC221.2080200@gmx.de> <CAJE5ia-hBNmYuhjWXsjke_QWT9pU_3N0XeGw+xo1ArMqSWa7TA@mail.gmail.com>
From: Adam Barth <ietf@adambarth.com>
Date: Sat, 29 Oct 2011 11:51:07 -0700
Message-ID: <CAJE5ia8DM7ont+fqY6yKe0ZJQvyS7UjYUdoF4RDX0HVZh-cCBQ@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 18:51:41 -0000

On Sat, Oct 29, 2011 at 11:50 AM, Adam Barth <ietf@adambarth.com> wrote:
> On Sat, Oct 29, 2011 at 2:06 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
>> On 2011-10-29 10:21, Adam Barth wrote:
>>> ...
>>>>
>>>> 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.
>>> ...
>>
>> So your points were about quoted-string in general, not the question of
>> allowing them for max-age, right?
>>
>> I'm asking because due the possible presence of extension parameters,
>> recipients need to deal with quoted-string anyway, no matter whether they
>> are allowed for max-age.
>
> I'm saying we shouldn't use quoted-string anywhere in the grammar
> because it makes the error-handling ill-defined.
>
> Here's the code I wrote to parse the header:
>
> http://src.chromium.org/viewvc/chrome/trunk/src/net/base/transport_security_state.cc?revision=106333&view=markup
>
> TransportSecurityState::ParseHeader
>
> I'm happy to change that code to allow the parameters to appear in any
> order and to allow other semi-colin separated fields.  Here's the
> parsing algorithm I'm willing to implement:
>
> 1) Split the header field value on ";".
> 2) Process each substring in sequence:
>  a) Remove leading and trailing LWS from the substring.
>  b) If the substring is a case-insensitive match for
> "includeSubDomains", set the include-subdomains flag and continue to
> the next substring.
>  c) If the substring contains at least one "=", let the characters
> before the first "=" be the parameter-name and let the characters
> after the first "=" be the parameter-value:
>    i) Strip leading and trailing LWS from both the parameter-name and
> the parameter-value.
>    ii) If the parameter-name is a case insensitive match for
> "max-age" and the parameter-value is non-empty and consists entirely
> of digits:
>      A) Let the max-age be the number represented by the digits and
> continue to the next substring.
>  d) Continue to the next substring.
>
> Notice that this algorithm defines behavior for all inputs and doesn't
> balance quotation marks in extension parameters.  Here's a
> representation of that algorithm in ABNF:
>
> value = paramater *(";" parameter)
> paramater = "includeSubDomains" / "max-age" "=" 1*DIGIT *LWS / extension
> extension = <any character aside from ";">

Sorry,

extension = *<any character aside from ";">

of course.

> If you want the specification to match the code, you need to take into
> account the desires of implementors.  In particular, you need to take
> into account the fact that implementations need to do something for
> every possible input and that browser implementors wish to be
> instructed how to handle every possible input.
>
> The net-net of this discussion is that's what the code is going to do.
>  If you'd like the specification to match the code, I'd recommend
> against adding aspirational quoted-strings to the grammar.
>
> Adam
>