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

From: =JeffH <[email-masked]>
Date: Mon, 04 Jun 2012 13:10:45 -0700

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 04 Jun 2012 21:20:39 +0100

On 04/06/2012 21:10, =JeffH wrote:
> thanks, yes, I believe that's correct. Here's what I have upon 
> re-writing it (this is in S 6.1)...
>

This looks good to me now.