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

[Alexey Melnikov <[e-mail]>]

On 04/06/2012 21:10, =JeffH wrote:
>
> > 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.

This looks good to me now.