Re: [websec] Strict-Transport-Security syntax redux

Julian Reschke <julian.reschke@gmx.de> Sat, 08 October 2011 18:19 UTC

Return-Path: <julian.reschke@gmx.de>
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 935CA21F8BA6 for <websec@ietfa.amsl.com>; Sat, 8 Oct 2011 11:19:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.082
X-Spam-Level:
X-Spam-Status: No, score=-103.082 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 uOQX+2ltaoov for <websec@ietfa.amsl.com>; Sat, 8 Oct 2011 11:19:16 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 3256E21F8BD8 for <websec@ietf.org>; Sat, 8 Oct 2011 11:19:15 -0700 (PDT)
Received: (qmail invoked by alias); 08 Oct 2011 18:22:31 -0000
Received: from p5DCC80F9.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.128.249] by mail.gmx.net (mp070) with SMTP; 08 Oct 2011 20:22:31 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19iqXspMhNilfAyCkP7o7sokUcQwcx0ZR2AuBWGG6 Z2cR3AyPzsMF+x
Message-ID: <4E9094E5.5070704@gmx.de>
Date: Sat, 08 Oct 2011 20:22:29 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: =JeffH <Jeff.Hodges@KingsMountain.com>
References: <4E8E388B.8020202@KingsMountain.com>
In-Reply-To: <4E8E388B.8020202@KingsMountain.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] Strict-Transport-Security syntax redux
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Sat, 08 Oct 2011 18:19:20 -0000

On 2011-10-07 01:23, =JeffH wrote:
> ...

Trying to summarize my concerns and proposals...

(1) RFC2616-or-HTTPbis

In a perfect world I could give you an exact time-of-arrival for 
HTTPbis. But the world is not perfect; and progress on HTTPbis mainly 
depends on the availability of the editors, and, more importantly, 
people showing up on the HTTPbis mailing list to help in closing issues 
and reviewing the existing text. So help *is* appreciated. -> 
<http://trac.tools.ietf.org/wg/httpbis/trac/wiki>

(2) Multiple header instances

Header fields can occur multiple times, even when they were intended not 
to. Examples: Location, Content-Length. When this happens, we usually 
see interop problems because some consumers pick the first, some pick 
the second, and some combine them using a comma, as described in HTTP spec.

This can be dangerous when the repetition makes the message format 
ambiguous (Content-Length, for instance). It also means that it allows 
smuggling, relying on checkers/intermediaries only seeing one of the 
headers.

Note that Chrome and FF have become very strict in checking for this for 
C-L, and FF does even more checks (syntax of C-L, also checks for 
Location and Content-Disposition).

So *if* STS doesn't allow multiple header fields (which would require 
switching to a comma-separated syntax), the spec should be crystal clear 
what to do when multiple instances are encountered; in many cases the 
default should be "ignore the header field" or even "consider the 
message to be broken". Not sure what's best here.

Also note that somebody else may be combining multiple fields into a 
single one, and the recipient will see those concatenated with commas as 
separators. Optimally the format is robust enough to detect things like 
that.

(3) ABNF organization

Any header field that is extensible needs to define the syntax for the 
extension point, so existing code can parse them. Don't make extensions 
different from the builtins with respect to syntax. It just makes the 
parser more complicated.

So just define a single ABNF for STS directives in ABNF.

For instance, using RFC 2616 ABNF and list syntax:

Strict-Transport-Security =
   "Strict-Transport-Security" ":" 1#directive

...or when sticking to semicolon:

Strict-Transport-Security =
   "Strict-Transport-Security" ":" directive *( ";" directive )

Then

directive = token( "=" ( token / quoted-string ) )

In prose, add additional constrains, such as "MUST contain FOOBAR 
directive exactly once".

Finally, for each builtin directive state the individual syntax of the 
param *value*, and do not make the ABNF vary based on the directive.

Hope this helps.

Also worth reading: 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#considerations.for.creating.header.fields>

Best regards, Julian