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

Adam Barth <ietf@adambarth.com> Sat, 29 October 2011 18:50 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 68B0D21F8573 for <websec@ietfa.amsl.com>; Sat, 29 Oct 2011 11:50:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.456
X-Spam-Level:
X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.521, 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 V1iMk+PZ3gBu for <websec@ietfa.amsl.com>; Sat, 29 Oct 2011 11:50:49 -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 B329121F84CB for <websec@ietf.org>; Sat, 29 Oct 2011 11:50:49 -0700 (PDT)
Received: by iabn5 with SMTP id n5so6765385iab.31 for <websec@ietf.org>; Sat, 29 Oct 2011 11:50:49 -0700 (PDT)
Received: by 10.231.6.102 with SMTP id 38mr2699765iby.62.1319914249339; Sat, 29 Oct 2011 11:50:49 -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 g16sm18137975ibs.8.2011.10.29.11.50.47 (version=SSLv3 cipher=OTHER); Sat, 29 Oct 2011 11:50:47 -0700 (PDT)
Received: by iabn5 with SMTP id n5so6765354iab.31 for <websec@ietf.org>; Sat, 29 Oct 2011 11:50:47 -0700 (PDT)
Received: by 10.231.48.142 with SMTP id r14mr2779420ibf.5.1319914247063; Sat, 29 Oct 2011 11:50:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.205.195 with HTTP; Sat, 29 Oct 2011 11:50:16 -0700 (PDT)
In-Reply-To: <4EABC221.2080200@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> <CAJE5ia-oOiBb2FTj_8Hxg9dyy=Oq8Y++VvLeQS=q2CUR1edHDQ@mail.gmail.com> <4EABC221.2080200@gmx.de>
From: Adam Barth <ietf@adambarth.com>
Date: Sat, 29 Oct 2011 11:50:16 -0700
Message-ID: <CAJE5ia-hBNmYuhjWXsjke_QWT9pU_3N0XeGw+xo1ArMqSWa7TA@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1
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:50:50 -0000

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