Re: [websec] Strict-Transport-Security syntax redux
=JeffH <Jeff.Hodges@KingsMountain.com> Sat, 29 October 2011 02:36 UTC
Return-Path: <Jeff.Hodges@KingsMountain.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 A294811E8089 for <websec@ietfa.amsl.com>; Fri, 28 Oct 2011 19:36:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.084
X-Spam-Level:
X-Spam-Status: No, score=-100.084 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 bRVkK-Td1kXh for <websec@ietfa.amsl.com>; Fri, 28 Oct 2011 19:36:39 -0700 (PDT)
Received: from oproxy4-pub.bluehost.com (oproxy4.bluehost.com [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 63AB621F84B1 for <websec@ietf.org>; Fri, 28 Oct 2011 19:36:38 -0700 (PDT)
Received: (qmail 3031 invoked by uid 0); 29 Oct 2011 02:36:37 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 29 Oct 2011 02:36:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=7KUeFo5iWbreTaqDhGLR6hepI3nYYT9NaXwnZVdhsdI=; b=Su7rMnFLOh+J9YNtiFNHgoM94Yi+1jTCXnS/CNVzfVkHD8cUjZjG7tPefXskyq8UBP1p4P6bDpSgQEPuwvmTr6+jPjNeQrhqeDnWJ+xRzxwrx2Agv2VvZhReoI92Qoai;
Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.242]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1RJymj-0000Wl-JJ; Fri, 28 Oct 2011 20:36:37 -0600
Message-ID: <4EAB66B3.4090404@KingsMountain.com>
Date: Fri, 28 Oct 2011 19:36:35 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>, Ryan Sleevi <ryan-ietfhasmat@sleevi.com>, IETF WebSec WG <websec@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
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, 29 Oct 2011 02:36:39 -0000
>> Strict-Transport-Security = "Strict-Transport-Security" ":" >> directive *( ";" [ directive ] ) >> >> STS directives: >> >> directive = max-age | includeSubDomains | STS-d-ext >> >> max-age = "max-age" "=" delta-seconds > > What happens with > > max-age="1" > > ? > > Do you expect all recipients to reject this? Depending on the parsing > API they use they might not even know that the value was quoted on the wire. Offhand, I'm not super sure, but after thinking about it while researching/writing the below, I'm thinking "yes", max-age="1" is invalid according to the ABNF and we should do whatever we do in error cases (which is a separate open question). But implementors' parsing API and its problems are out-of-scope for a spec such as this. This obviously isn't the first HTTP response header field with such a syntax and thus these potential issues (this one with a delta-seconds value, and the issue you note below wrt "includeSubDomains"), yes? In doing a quick grep on RFCs for delta-seconds, I note that some of the specs using it (I didn't look at them all) appear to not directly address the case above. Except for RFC6265, which in the algorithm for parsing "Max-Age=", it algorithmically provides for ignoring a value that doesn't match the effective value ABNF of.. ["-"]*DIGIT ..which would catch the max-age="1" case, but doesn't seem to explicitly address.. max-age= But in any case, perhaps (additional) browser implementor folk could chime in here -- do we really need to address such detail-level issues (both of the examples above and below) in the syntax/grammar we specify in specs such as these? Or is the new ABNF proposed in the original message in this thread sufficient? > > includeSubDomains = "includeSubDomains" > > There's a tiny risk that some implementations will handle value-less > parameters the same way as parameters with empty values, such as > > includeSubDomains= > > or > > includeSubDomains="" > > but maybe I'm over-engineering here. Yes, I'm wondering if this might be over-engineering -- I note that in RFC 6266 you didn't distinguish/address this sort of case for "inline" or "attachment" -- are you feeling now that you should have, and thus we ought to do so going forward? > Also, identifiers "max-age" and "includeSubDomains" are > case-insensitive, right? This follows from the ABNF, yes, and yes. > but might be worth > saying again in prose; in particular because it also needs to be the > case for all future extensions. Agreed. I see how you did it in RFC 6266 and will endeavor to do similarly. thanks again, =JeffH
- [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