[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, 02 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
- [websec] Strict-Transport-Security syntax redux Ryan Sleevi
- Re: [websec] Strict-Transport-Security syntax red… =JeffH
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- [websec] Strict-Transport-Security syntax redux =JeffH
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… =JeffH
- Re: [websec] Strict-Transport-Security syntax red… =JeffH
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Phillip Hallam-Baker
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Bjoern Hoehrmann
- Re: [websec] Strict-Transport-Security syntax red… Phillip Hallam-Baker
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… =JeffH
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Roy T. Fielding
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Tobias Gondrom
- Re: [websec] Strict-Transport-Security syntax red… Anne van Kesteren
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Paul Hoffman
- Re: [websec] Strict-Transport-Security syntax red… Anne van Kesteren
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Anne van Kesteren
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Bjoern Hoehrmann
- Re: [websec] Strict-Transport-Security syntax red… Adam Barth
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Paul Hoffman
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Marsh Ray
- Re: [websec] Strict-Transport-Security syntax red… Julian Reschke
- Re: [websec] Strict-Transport-Security syntax red… Bjoern Hoehrmann