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

Phillip Hallam-Baker <hallam@gmail.com> Sun, 30 October 2011 12:31 UTC

Return-Path: <hallam@gmail.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 387D021F86A4 for <websec@ietfa.amsl.com>; Sun, 30 Oct 2011 05:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.431
X-Spam-Level:
X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 MvsaOuWIfMnf for <websec@ietfa.amsl.com>; Sun, 30 Oct 2011 05:31:37 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB4221F8888 for <websec@ietf.org>; Sun, 30 Oct 2011 05:31:36 -0700 (PDT)
Received: by ggnv1 with SMTP id v1so5973219ggn.31 for <websec@ietf.org>; Sun, 30 Oct 2011 05:31:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hoNelf4v99q+tGOOGZQRzP9YLERMXYRmn4nToPhRYcg=; b=mmQtkhyg6TsaFJScwIpERBO2x2owgrWi4/9T2Gq9ugI6idWTx+4TeK1z8XAMIYkGdd 8wc48SaNN99AZwfYVG/txQcguT63IV/tr6qsK/w1v6OKyLaVGfAPZ40TCfCCDV4v098h olZkgf2Qh8X2L1KVhz48rXJzxxB3XB1J7IWqg=
MIME-Version: 1.0
Received: by 10.182.115.40 with SMTP id jl8mr2093693obb.8.1319977896396; Sun, 30 Oct 2011 05:31:36 -0700 (PDT)
Received: by 10.182.42.99 with HTTP; Sun, 30 Oct 2011 05:31:36 -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>
Date: Sun, 30 Oct 2011 08:31:36 -0400
Message-ID: <CAMm+LwiUmNrnUMwVP2FStSEAPUKeHQwc-M+dqyKksgk4gHjRZQ@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Adam Barth <ietf@adambarth.com>
Content-Type: multipart/alternative; boundary=f46d0444808ba0474104b0834dfa
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: Sun, 30 Oct 2011 12:31:38 -0000

I think that the field is going to match the requirements of the HTTP spec:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2

       message-header = field-name ":" [ field-value ]
       field-name     = token
       field-value    = *( field-content | LWS )
       field-content  = <the OCTETs making up the field-value
                        and consisting of either *TEXT or combinations
                        of token, separators, and quoted-string>


That takes precedence over the desire to scrape together naive parsers in
my view.

Most people writing code are going to want to skip the need to write a
parser altogether by using existing parser methods built in to their
platform.

This is a standards based specification and so it has to match the format
already defined by the HTTP specification and aspirational or not, any code
that fails to match quoted string is likely to break in future spec
versions.


On Sat, Oct 29, 2011 at 2:50 PM, 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 ";">
>
> 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
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
>



-- 
Website: http://hallambaker.com/