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

Julian Reschke <julian.reschke@gmx.de> Fri, 30 December 2011 10:00 UTC

Return-Path: <julian.reschke@gmx.de>
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 E37DD21F8B54 for <websec@ietfa.amsl.com>; Fri, 30 Dec 2011 02:00:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.428
X-Spam-Level:
X-Spam-Status: No, score=-103.428 tagged_above=-999 required=5 tests=[AWL=-0.829, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 LcXDMvR8sc1d for <websec@ietfa.amsl.com>; Fri, 30 Dec 2011 02:00:56 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1875521F8B4E for <websec@ietf.org>; Fri, 30 Dec 2011 02:00:55 -0800 (PST)
Received: (qmail invoked by alias); 30 Dec 2011 10:00:52 -0000
Received: from p3EE2751C.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.117.28] by mail.gmx.net (mp033) with SMTP; 30 Dec 2011 11:00:52 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX197fXBIw7R7+UGtfSPnq+PiIeReAokl5+74txYwSy a8LhiViJfB3tBs
Message-ID: <4EFD8BCE.7010909@gmx.de>
Date: Fri, 30 Dec 2011 11:00:46 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Adam Barth <ietf@adambarth.com>
References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <CAJE5ia_HhenArVey=5-ttLqh4-vbBE01TFZKuzAmAtHQJQJ3kQ@mail.gmail.com> <4EFCD7E4.5060507@gmx.de> <CAJE5ia-w47HHhnTBAE_PMApAAdCu=6PJexaaoJO0MZ23Ae-vcw@mail.gmail.com> <4EFCDA9C.90308@gmx.de> <CAJE5ia-E1nhN1YGV6uy3uEq4oboQowDm4FboKbWV1kunHQmXPw@mail.gmail.com> <4EFCDDD5.6040005@gmx.de> <CAJE5ia8CL9ozRJgRNCdu6XwVT0paVuVUreB12f-BiMvH+wiq6A@mail.gmail.com> <4EFD73E6.1060506@gmx.de> <CAJE5ia8RBa8iCd_9TjXyzG54VASa6qqGomsO9gL-qQ2ia=BKLg@mail.gmail.com> <4EFD7C09.9050702@gmx.de> <CAJE5ia8aN_MKUX_7ehp6siw=CY7nC4aSRPoPcsaDX8+emwaFVw@mail.gmail.com>
In-Reply-To: <CAJE5ia8aN_MKUX_7ehp6siw=CY7nC4aSRPoPcsaDX8+emwaFVw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
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 10:00:58 -0000

On 2011-12-30 10:13, Adam Barth wrote:
> Using quoted-string in the extension directive is the wrong thing to
> do.  Because none of the actual directives use quoted-string, folks
> are likely to write parsers that don't handle all the complexities of
> quoted-string (which are legion).  That means when we go to actually
> use quoted-string in a future directive, it won't actually work in
> many user agents.

Unless we clarify the syntax, allow q-s everywhere, and have test cases.

> On the other hand, if we spec the extension directives without
> quoted-string, future extensions will work even if folks mistakenly
> implement quote-string (because DQUOTE is forbidden in the extension
> syntax I suggested above, so we'll never trigger the mistaken
> quoted-string parsing code).  Everyone lives a happy life.

Absolutely not.

First of all, some implementations will parse q-s, because that's 
consistent with other header fields. Also, not having q-s makes certain 
values impossible to send, in which case you'll need to invent yet 
another escaping syntax.

> Anyway, it's all somewhat of a moot point because the above will
> happen regardless of what we write in the spec.  Even if we write
> quoted-string, when folks attempt to use these extension directives in
> the future, they'll find that they don't work and they'll update the
> syntax not to use quoted-string.

Why would they find that? Implementations can be fixed.

Or is this argument based on the fact that you *currently* "own" one 
implementation and claim it can't be fixed? That would be a very strange 
thing to do in the context of an IETF WG trying to reach consensus.

Best regards, Julian

PS: I note that we are in violent agreement that the syntax should be 
the same for all directives, predefined or extension. We just come to 
different conclusions about what that syntax should be.