Re: [websec] ignoring STS header fields with undefined directives (was: new rev: draft-ietf-websec-strict-transport-sec-08)

=JeffH <Jeff.Hodges@KingsMountain.com> Mon, 04 June 2012 20:10 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 7667D11E80BA for <websec@ietfa.amsl.com>; Mon, 4 Jun 2012 13:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.346
X-Spam-Level:
X-Spam-Status: No, score=-100.346 tagged_above=-999 required=5 tests=[AWL=0.149, 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 Ypa5rcyOgdT5 for <websec@ietfa.amsl.com>; Mon, 4 Jun 2012 13:10:45 -0700 (PDT)
Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 21E5F11E80CC for <websec@ietf.org>; Mon, 4 Jun 2012 13:10:44 -0700 (PDT)
Received: (qmail 9474 invoked by uid 0); 4 Jun 2012 20:10:44 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com with SMTP; 4 Jun 2012 20:10:44 -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:CC:To:MIME-Version:From:Date:Message-ID; bh=1jOIswVUcNKleUoN4BJEM0Ks5pIGCxr1UH7U5QJqrAk=; b=HC3FMT/zHAb4kW8gC6l5nMOnIQmkbIuboV63lYjMdY3+CTDBEwX+VRBvbUd3dv6Bw5D+NUBC+A2Z1aHCeI+vtSVYS+GS8qdsbntCRom/LefyBdt2ygIK6nTUYI6nwu72;
Received: from [216.113.168.128] (port=31192 helo=[10.244.136.116]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1Sbdbw-00075Q-74; Mon, 04 Jun 2012 14:10:44 -0600
Message-ID: <4FCD1645.3050700@KingsMountain.com>
Date: Mon, 04 Jun 2012 13:10:45 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
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}
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] ignoring STS header fields with undefined directives (was: new rev: draft-ietf-websec-strict-transport-sec-08)
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: Mon, 04 Jun 2012 20:10:49 -0000

 > On 2012-06-02 02:22, =JeffH wrote:
 >>  > On 2012-06-01 20:32, =JeffH wrote:
 >>  >
 >>  >> Alexey wrote:
 >>  >>
 >>  >> > Most of my issues were addressed in the latest version, except for
 >>  >> this one:
 >>  >> >
 >>  >> > > 6.1. Strict-Transport-Security HTTP Response Header Field
 >>  >> > >
 >>  >> > > 4. UAs MUST ignore any STS header fields containing directives, or
 >>  >> > > other header field value data, that does not conform to the
 >>  >> > > syntax defined in this specification.
 >>  >> >
 >>  >> > So this is saying that syntactically invalid STS header fields are
 >>  >> > to be ignored. This still doesn't say if unrecognized directives
 >> are to
 >>  >> > be ignored or not. (Because they can comply with the generic
 >> syntax for
 >>  >> > directives, so they would be syntactically valid, albeit
 >> unrecognized).
 >>  >> > So can you please add an explicit sentence about that?
 >>  >>
 >>  >>
 >>  >> Here's the text in my working copy for that item..
 >>  >>
 >>  >> <t>
 >>  >> UAs MUST ignore any STS header fields containing
 >>  >> directives, or other header field value data, that does
 >>  >> not conform to the syntax defined in this specification.
 >>  >> UAs MUST also ignore any STS header fields containing
 >>  >> undefined directives.
 >>  >> </t>
 >>  >>
 >>  >> Ok?
 >>  >> ...
 >>  >
 >>  > That makes it basically impossible to add extensions; is that intended?
 >>
 >> No, that is not my intention, nor the WG's as far as I understand.
 >>
 >>
 >> Alexey follows up with:
 >>  >
 >>  > I agree with Julian: this will make the header field effectively non
 >>  > extensible. And if you update the header field by adding new values, all
 >>  > older implementations will start ignoring it, which is a deployment
 >>  > headache.
 >>
 >> Ok, so the first proposal is broken, how about this..
 >>
 >> <t>
 >> UAs MUST ignore any STS header fields containing
 >> directives, or other header field value data, that does
 >> not conform to the syntax defined in this specification.
 >> </t>
 >> <t>
 >> UAs MUST ignore any directives they
 >> do not recognize, but MAY accept and
 >> process a STS header field containing an
 >> unrecognized directive but otherwise
 >> satisfying the other
 >> requirements (1 through 4) stated here.
 >> </t>
 >>
 >> ..?
 >>
 >> Note that the paragraph following the above numbered list items states:
 >>
 >> Additional directives extending the semantic functionality of the STS
 >> header field can be defined in other specifications.
 >
 > "UAs MUST ignore any directives they do not recognize, ..."
 >
 > Yes.
 >
 > " ...but MAY accept and process a STS header field containing an
 > unrecognized directive but otherwise satisfying the other requirements
 > (1 through 4) stated here."
 >
 > Why "MAY accept" here? If the MUST ignore extension directives, doesn't
 > that mean that that "MAY" indeed is a "MUST"?

thanks, yes, I believe that's correct. Here's what I have upon re-writing it 
(this is in S 6.1)...

    4.  UAs MUST ignore any STS header fields containing directives, or
        other header field value data, that does not conform to the
        syntax defined in this specification.

    5.  If an STS header field contains directive(s) not recognized by
        the UA, the UA MUST ignore the unrecognized directives and if the
        STS header field otherwise satisfies the above requirements (1
        through 4), the UA MUST process the recognized directives.

    Additional directives extending the semantic functionality of the STS
    header field can be defined in other specifications.


=JeffH