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

Adam Barth <ietf@adambarth.com> Mon, 09 January 2012 00:26 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 7786B21F85D6 for <websec@ietfa.amsl.com>; Sun, 8 Jan 2012 16:26:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.714
X-Spam-Level:
X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[AWL=0.263, 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 gt99CQPAAVET for <websec@ietfa.amsl.com>; Sun, 8 Jan 2012 16:26:03 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0B5121F849C for <websec@ietf.org>; Sun, 8 Jan 2012 16:26:03 -0800 (PST)
Received: by iabz21 with SMTP id z21so6488135iab.31 for <websec@ietf.org>; Sun, 08 Jan 2012 16:26:03 -0800 (PST)
Received: by 10.50.207.72 with SMTP id lu8mr16956520igc.0.1326068763422; Sun, 08 Jan 2012 16:26:03 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id 36sm244238590ibc.6.2012.01.08.16.26.02 (version=SSLv3 cipher=OTHER); Sun, 08 Jan 2012 16:26:02 -0800 (PST)
Received: by iabz21 with SMTP id z21so6488113iab.31 for <websec@ietf.org>; Sun, 08 Jan 2012 16:26:02 -0800 (PST)
Received: by 10.42.151.195 with SMTP id f3mr13655565icw.19.1326068762124; Sun, 08 Jan 2012 16:26:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.62.139 with HTTP; Sun, 8 Jan 2012 16:25:31 -0800 (PST)
In-Reply-To: <aoakg7l45gfcrj731u6k652hjofhv12ocl@hive.bjoern.hoehrmann.de>
References: <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> <aoakg7l45gfcrj731u6k652hjofhv12ocl@hive.bjoern.hoehrmann.de>
From: Adam Barth <ietf@adambarth.com>
Date: Sun, 08 Jan 2012 16:25:31 -0800
Message-ID: <CAJE5ia-5X_onfhUriRkQZNbVBa_qRBYPkUu8kyEVsrGmE41_=Q@mail.gmail.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Content-Type: text/plain; charset="ISO-8859-1"
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: Mon, 09 Jan 2012 00:26:04 -0000

On Sun, Jan 8, 2012 at 4:10 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> * Tobias Gondrom wrote:
>><hat="chair>
>>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.
>
> It seems to me that all headers defined in RFC 2616 that allow para-
> meteter lists of the `;name=value` form allow the value to be a quoted
> string.

This header isn't defined in RFC 2616 and many headers defined outside
of RFC 2616 don't use quoted-string.

Adam


> If the Working Group wishes to disallow quoted strings, then
> it should use a format that's very different from the existing syntax,
> like `name=value&name=other%20value` or JSON or whatever. "Similar but
> slightly different" always translate into bugs.