Re: [websec] WG Last Call on draft-ietf-websec-strict-transport-sec-06 until April-9

Marsh Ray <> Mon, 19 March 2012 17:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3307021F8852 for <>; Mon, 19 Mar 2012 10:05:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.574
X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LV1lO2EVkAmN for <>; Mon, 19 Mar 2012 10:05:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9458521F884F for <>; Mon, 19 Mar 2012 10:05:07 -0700 (PDT)
Received: from ([]) by with esmtpa (Exim 4.72) (envelope-from <>) id 1S9g14-000G7v-76; Mon, 19 Mar 2012 17:05:06 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id B39CA6081; Mon, 19 Mar 2012 17:05:04 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX193lfibhIt0DiIuz0ZhCIbj0jLB+0p59zg=
Message-ID: <>
Date: Mon, 19 Mar 2012 12:05:04 -0500
From: Marsh Ray <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20120216 Thunderbird/3.1.19
MIME-Version: 1.0
To: Julian Reschke <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [websec] WG Last Call on draft-ietf-websec-strict-transport-sec-06 until April-9
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Mar 2012 17:05:08 -0000

On 03/19/2012 04:35 AM, Julian Reschke wrote:
> I'd like to point out that I still think my concerns over the
> inconsistent use of quoted-string
> (<>)
> are valid and not addressed; and I think they should be before you go to

As a developer at a company which makes a product that makes security 
decisions based on parsing HTTP headers I find Julian's concerns, well, 

While we don't currently operate on this specific header, ambiguities in 
how an application server will interpret minor variations on header 
values often become opportunities for an attacker to bypass security 
measures. For example, a "web application firewall" (WAF) may be 
configured to forbid certain values of a customer-specified header. When 
new headers don't follow consistent syntactic rules, it takes away a bit 
of the developer's ability to simply things for his customer.

Again, I'm not claiming to be an expert on this particular header and 
clearly it's a difficult issue with arguments for doing it both ways. 
But I would ask that everyone try their best to find the least-bad 
alternative with an emphasis on consistency with the rest of HTTP.

- Marsh