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

Adam Barth <ietf@adambarth.com> Fri, 30 December 2011 06:09 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 DA68C11E807F for <websec@ietfa.amsl.com>; Thu, 29 Dec 2011 22:09:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 8n5n3hjhYUe7 for <websec@ietfa.amsl.com>; Thu, 29 Dec 2011 22:09:58 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 26E7D21F8B6D for <websec@ietf.org>; Thu, 29 Dec 2011 22:09:57 -0800 (PST)
Received: by yhjj72 with SMTP id j72so9505130yhj.31 for <websec@ietf.org>; Thu, 29 Dec 2011 22:09:56 -0800 (PST)
Received: by 10.236.155.74 with SMTP id i50mr50771046yhk.23.1325225395939; Thu, 29 Dec 2011 22:09:55 -0800 (PST)
Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id n64sm53740018yhk.4.2011.12.29.22.09.54 (version=SSLv3 cipher=OTHER); Thu, 29 Dec 2011 22:09:55 -0800 (PST)
Received: by obcuz6 with SMTP id uz6so11363097obc.31 for <websec@ietf.org>; Thu, 29 Dec 2011 22:09:54 -0800 (PST)
Received: by 10.50.6.233 with SMTP id e9mr44399739iga.17.1325225394101; Thu, 29 Dec 2011 22:09:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.62.139 with HTTP; Thu, 29 Dec 2011 22:09:23 -0800 (PST)
In-Reply-To: <168B10CA-0522-4A60-BAC8-597472B79882@gbiv.com>
References: <4EFD0D7D.7040908@KingsMountain.com> <CAJE5ia8L4UV-06JXVXZ1KuHd9hg=0KoaqxSX3W7RSwoCE8tQTA@mail.gmail.com> <168B10CA-0522-4A60-BAC8-597472B79882@gbiv.com>
From: Adam Barth <ietf@adambarth.com>
Date: Thu, 29 Dec 2011 22:09:23 -0800
Message-ID: <CAJE5ia_zgQGeKH0aThUed5yXkfBKC+m79o=Vj1ikq9CpP579hQ@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
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: Fri, 30 Dec 2011 06:09:59 -0000

On Thu, Dec 29, 2011 at 8:11 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
> On Dec 29, 2011, at 5:22 PM, Adam Barth wrote:
>> On Thu, Dec 29, 2011 at 5:01 PM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote:
>>> Adam Barth noted:
>>>> I would also define the precise requirements for parsing all possible
>>>> input sequences, but I understand that's not fashionable.
>>>
>>> By that, you are suggesting specification of parsing algorithms as done in
>>> RFC6265 "HTTP State Management Mechanism", yes?
>>
>> I actually think what we're doing for CSP is slightly better:
>>
>> http://www.w3.org/TR/CSP/#policies
>
> Hmm, that algorithm breaks on
>
>   foo;;bob
>
> which is allowed by the associated ABNF.  *shrug*

I'm not sure I understand what you think breaks about the algorithm.
I've restricted the loop to non-empty tokens, which hopefully
addresses your concern.

> I don't think I'll ever understand why you keep promoting Ian's
> mantra on specs being written as algorithms.  The algorithms that
> you end up placing in the specs have more bugs than the code
> found in the actual implementations, and they aren't any more
> formal than the ABNF.

The problem is that the ABNF simply doesn't define how to handle error
conditions.  At least with algorithms they define the behavior.  If
the definition is wrong or has bugs, we can fix those bugs.
Eventually the process converges to a correct definition of the
behavior.

Adam