[websec] Strict-Transport-Security syntax redux

"Ryan Sleevi" <ryan-ietfhasmat@sleevi.com> Sun, 02 October 2011 10:40 UTC

Return-Path: <ryan-ietfhasmat@sleevi.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 04F2021F8E51 for <websec@ietfa.amsl.com>; Sun, 2 Oct 2011 03:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2ShnMxu5bUYm for <websec@ietfa.amsl.com>; Sun, 2 Oct 2011 03:40:04 -0700 (PDT)
Received: from homiemail-a63.g.dreamhost.com (caiajhbdcaib.dreamhost.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3A1A821F8E4B for <websec@ietf.org>; Sun, 2 Oct 2011 03:40:04 -0700 (PDT)
Received: from homiemail-a63.g.dreamhost.com (localhost []) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 6F8FF2F4059 for <websec@ietf.org>; Sun, 2 Oct 2011 03:43:03 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sleevi.com; h=message-id:date :subject:from:to:reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=sleevi.com; b=cLcVi4kGGn9Cr2 7ESEOR0Zjx99ylWqj8k9/oHCoY6pdDU+fk+i6FmeWAu13rqw6HoX9pXywCVQgzxX 3MCeE9xl50k4sUQ/s6wOClP06dPcqcOEk06Qzw2AIbmhCqODT3xkY1oE9LzQKefd By7Fd0ZeqYC0kbYy4XA2bOGaS90Z0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :date:subject:from:to:reply-to:mime-version:content-type: content-transfer-encoding; s=sleevi.com; bh=ss4bXY+DNS3hOb/UA5Kh 8oMgrG8=; b=KlzRPNvRtY2Tap2psUOU8qnw1pmN9dKWkVDSa5GteKwsa/EskpHe ELoyoYKKHqjy9JOXWg26XAWK9s4rAVckoURqlQnKu8aRBFFrj9oOXukwxam2vh+8 eSPOW3q4qrY4TBQ0pnqLN4na4QkFzEi6GqgPLgoF/TI11aUr3faehr8=
Received: from webmail.sleevi.com (ahfbbjcaiaae.dreamhost.com []) (Authenticated sender: ryan@sleevi.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPA id 637682F401C for <websec@ietf.org>; Sun, 2 Oct 2011 03:43:03 -0700 (PDT)
Received: from (proxying for (SquirrelMail authenticated user ryan@sleevi.com) by webmail.sleevi.com with HTTP; Sun, 2 Oct 2011 06:43:03 -0400
Message-ID: <d9eb0f8b774c7309b6144cd1ec2c147c.squirrel@webmail.sleevi.com>
Date: Sun, 2 Oct 2011 06:43:03 -0400
From: "Ryan Sleevi" <ryan-ietfhasmat@sleevi.com>
To: websec@ietf.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: [websec] Strict-Transport-Security syntax redux
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ryan-ietfhasmat@sleevi.com
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: Sun, 02 Oct 2011 10:40:05 -0000

Following Julian Reschke's questions, I also had a few questions related
to the draft-02 syntax. I've been basing my understanding on RFC 5234,
which I understand to be the most current/relevant to understanding the

First, maxAge and includeSubDomains both include value extension points,
defined as:

	maxAge     = "max-age"  OWS  "="  OWS  delta-seconds  [ OWS v-ext ]
	includeSubDomains =  "includeSubDomains"  [ OWS v-ext ]
	v-ext      = value     ; STS extension value

However, the rule for OWS is specified as:

	OWS       = *( [ CRLF ] WSP )

As written, it would seem that the OWS between either delta-seconds or
"includeSubDomains" can legitimately be omitted before the v-ext. As best
I can tell, this would mean that the following values would still be


In the first case ".456" is the v-ext, while in the second, "abc" is. In
both cases, because the OWS is truly optional (valid to have 0
occurrences), only the v-ext is present. For maxAge in particular, this
can lead to very silly parsing interpretations. Considering the following


If I'm not mistaken, ABNF doesn't specify any sort of greedy matching, so
this could be interpreted as:
	delta-seconds = 1 (1DIGIT), v-ext = 23 (0OWS 2tchar)
	delta-seconds = 12 (2DIGIT), v-ext = 3 (0OWS 1tchar)

To remedy this, I believe some form of explicit delimiter between the
existing values and the v-ext should be defined for the existing headers.
If the intent was to have extension values whitespace separated, then
would the following modification to introduce required whitespace solve

	maxAge     = "max-age"  OWS  "="  OWS  delta-seconds  [ RWS v-ext ]
	includeSubDomains =  "includeSubDomains"  [ RWS v-ext ]
	v-ext      = value     ; STS extension value
	OWS       = *( [ CRLF ] WSP )
	RWS       = 1*( [ CRLF ] WSP )

Alternatively, can/should the v-ext be dropped entirely, and extensions to
the STS header be accomplished via defining a new STS-d-ext?

Second, as currently specified, extension directives take the form of:

	STS-d      = STS-d-cur / STS-d-ext
	STS-d-ext  = name      ; STS extension directive
	name       = token
	token      = 1*tchar
	tchar      = "!" / "#" / "$" / "%" / "&" / "'" / "*"
      	     / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
	           / DIGIT / ALPHA

As currently written, STS-d-ext doesn't seem to be able to contain name
"=" value pairs such as those used by Evans' and Palmer's pinning draft,
because "=" is not a valid token character. Likewise, it wouldn't be able
to contain "#rule" style lists, because comma is not a valid tchar.

Should STS-d-ext be defined as "value" instead, so that it contain a wider
range of characters? Alternatively, if the intent for STS-d-ext was that
it would always include some name, should it be defined as "name [ OWS "="
OWS value ]"?

Either way seems to offer a solution. It seems that if a parser were
written based on the current draft, it would be correct/valid to reject an
STS header that included cert pins, as specified in the current pinning
draft. This would be because the cert pinning draft makes use of "="
within the extension definitions, which is not a legal character for an
STS-d-ext in the base spec.

Best regards,