Re: [websec] STS ABNF, was: new rev: draft-ietf-websec-strict-transport-sec-04

=JeffH <> Mon, 26 March 2012 06:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2491521E8083 for <>; Sun, 25 Mar 2012 23:38:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.751
X-Spam-Status: No, score=-99.751 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JmN+z+rUsAB1 for <>; Sun, 25 Mar 2012 23:38:54 -0700 (PDT)
Received: from ( [IPv6:2605:dc00:100:2::a3]) by (Postfix) with SMTP id 2739D21F8478 for <>; Sun, 25 Mar 2012 23:38:54 -0700 (PDT)
Received: (qmail 1844 invoked by uid 0); 26 Mar 2012 06:38:53 -0000
Received: from unknown (HELO ( by with SMTP; 26 Mar 2012 06:38:53 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=xeNangr3eGEf2Sct/kGYVwr4nFXlsPT/XguO7cP3/H4=; b=W7gNfb0DXA+Uo5w33EQdqMcnyZb3hzNzpX8gh7fprY34uH2J182O1Knmlc7e+wiQzCZH2Q72dzYv3Ps9mb+SiwMrTXxEPMk02RdSrPufQ3oLyvrU9v4TEdfVTuSJjXNa;
Received: from ([]) by with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from <>) id 1SC3Zs-0004JA-PD for; Mon, 26 Mar 2012 00:38:53 -0600
Message-ID: <>
Date: Sun, 25 Mar 2012 23:38:49 -0700
From: =JeffH <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: IETF WebSec WG <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {} {sentby:smtp auth authed with}
Subject: Re: [websec] STS ABNF, was: new rev: draft-ietf-websec-strict-transport-sec-04
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, 26 Mar 2012 06:38:55 -0000

 >>  >> sections 6.1.1 and 6.1.2 describe the syntax particular to max-age and
 >>  >> includeSubDomains directives, and neither of those directives employ
 >>  >> quoted-string, and I don't think they need to or should.
 >>  >
 >>  > I think they should, because it's likely that people will write parses
 >>  > that allow both, thus you'll have an automated (and totally unneeded)
 >>  > interoperatility problem.
 >> Well, i'm not terribly convinced about this, especially given my code
 >> reconnaissance in Firefox and Chrome.
 > When you checked Firefox, did it support quoted-string for extension
 > directives? See?

I am not sure what you mean by "See?" -- the parsers for STS header in both 
firefox and chrome are one-off hand-coded specific parsers, for better or worse 
(I'm not sure why they were done that way), and neither one supports 
quoted-string for anything in the STS header IIRC.

That said, given the present definitions of the STS directives...

     max-age       = "max-age" "=" delta-seconds

     delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2>

      includeSubDomains = "includeSubDomains"

I'm not sure how to cleanly and unambiguously define them in terms of both 
token and quoted-string (and retain max-age's basis on delta-seconds). Perhaps 
you could propose how to do this?

Also, we need to consciously realize that even if we define it in this fancier 
way in the spec, the present HSTS implementations won't match this, and may 
never do so. i.e. yes, you can submit bugs and wait and see what happens.



 >>  > I think they should, because it's likely that people will write parses
 >>  > that allow both,

I think "likely" should in reality be "may" in the above. There's a ton of 
parsers already written (firefox alone has several different ones apparently 
from what I can discern) that don't follow the (relatively recent) "parse 
parameter values in both token and quoted string forms" mantra.

And so you're hoping both that existing parsers get updated to follow the 
general guidelines in "3.1 Considerations for Creating Header Fields" 
and that new ones also adhere to said considerations.