[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 [127.0.0.1]) 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-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 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 [208.97.132.81]) 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 [127.0.0.1]) 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 [75.119.208.4]) (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 72.189.105.152 (proxying for 72.189.105.152) (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
syntax.


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
valid:

	max-age=123.456
	includeSubDomainsabc

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
value:

	max-age=123

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
it?

	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,
	Ryan