IETF Logo Mail Archive

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

Julian Reschke <julian.reschke@gmx.de> Thu, 05 January 2012 08:54 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 1CB9A21F8749 for <websec@ietfa.amsl.com>; Thu, 5 Jan 2012 00:54:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.742
X-Spam-Level:
X-Spam-Status: No, score=-103.742 tagged_above=-999 required=5 tests=[AWL=-1.143, 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 2aBYso9pYwRi for <websec@ietfa.amsl.com>; Thu, 5 Jan 2012 00:54:51 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E02E221F8751 for <websec@ietf.org>; Thu, 5 Jan 2012 00:54:50 -0800 (PST)
Received: (qmail invoked by alias); 05 Jan 2012 08:54:48 -0000
Received: from p5DCC2522.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.37.34] by mail.gmx.net (mp065) with SMTP; 05 Jan 2012 09:54:48 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1855NZDF285+AXpQzsQW47t0jsdC6pK/mx3Vx0ri+ tL3w6we8D5J6+q
Message-ID: <4F056553.9030409@gmx.de>
Date: Thu, 05 Jan 2012 09:54:43 +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: Anne van Kesteren <annevk@opera.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> <4EFD8BCE.7010909@gmx.de> <CAJE5ia9cziSx-xb6nCEFXJkbu2Ls_ZQmYHpfrC7UK3ig3ZmM2g@mail.gmail.com> <4F052D2E.5050200@gondrom.org> <op.v7lqsdyu64w2qv@annevk-macbookpro.local>
In-Reply-To: <op.v7lqsdyu64w2qv@annevk-macbookpro.local>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: 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: Thu, 05 Jan 2012 08:54:52 -0000

On 2012-01-05 09:20, Anne van Kesteren wrote:
> On Thu, 05 Jan 2012 05:55:10 +0100, Tobias Gondrom
> <tobias.gondrom@gondrom.org> wrote:
>> as it seems there is disagreement on how to resolve this, with only
>> very few people having spoken out so far, I would like to invite
>> comments from other working group members on this topic to see whether
>> we might have missed something.
>
> I don't really get what the advantage of allowing quoted string here is.
> If we can use a simpler production, what is wrong with using that?

The advantages are:

- you can express values that you can't express with token syntax; if 
future extensions need non-token characters they will need invent yet 
another escaping syntax

- principle of least surprise and consistency - if quoted-string works 
in other header fields with param syntax, why not here?

etc.

On the other hand, I haven't seen convincing arguments for not allowing 
q-s. Yes, it adds to the complexity of the parser, but this has been 
implemented many times before already.


Best regards, Julian

v2.23.0 | Report a Bug | By Email