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 >
- [websec] Strict-Transport-Security syntax redux Ryan Sleevi
- Re: [websec] Strict-Transport-Security syntax red… =JeffH
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- [websec] Strict-Transport-Security syntax redux =JeffH
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… =JeffH
- Re: [websec] Strict-Transport-Security syntax red… =JeffH
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Phillip Hallam-Baker
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Bjoern Hoehrmann
- Re: [websec] Strict-Transport-Security syntax red… Phillip Hallam-Baker
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… =JeffH
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Roy T. Fielding
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Tobias Gondrom
- Re: [websec] Strict-Transport-Security syntax red… Anne van Kesteren
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Paul Hoffman
- Re: [websec] Strict-Transport-Security syntax red… Anne van Kesteren
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Anne van Kesteren
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Bjoern Hoehrmann
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Paul Hoffman
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Marsh Ray
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Bjoern Hoehrmann