=JeffH | 3 Jan 00:29 2012

default value for max-age ? (was: Re: Strict-Transport-Security syntax redux)

Julian wondered..
 >
 > wouldn't it make sense to have a default for max-age so it
 > can be made OPTIONAL?

hm ... I lean towards keeping max-age as REQUIRED (without a default value) and 
thus hopefully encouraging deployers to think a bit about this and its 
ramifications, and also because its value is so site-specific in terms of a web 
application's needs, deployment approach, and tolerance for downside risk of 
breaking itself.

=JeffH

Chris Palmer | 3 Jan 01:35 2012
Picon

Re: default value for max-age ? (was: Re: Strict-Transport-Security syntax redux)

On Mon, Jan 2, 2012 at 3:29 PM, =JeffH <Jeff.Hodges <at> kingsmountain.com> wrote:

> hm ... I lean towards keeping max-age as REQUIRED (without a default value)
> and thus hopefully encouraging deployers to think a bit about this and its
> ramifications, and also because its value is so site-specific in terms of a
> web application's needs, deployment approach, and tolerance for downside
> risk of breaking itself.

I feel the same way for public key pinning, for the same reason.
Adam Barth | 3 Jan 01:50 2012

Re: default value for max-age ? (was: Re: Strict-Transport-Security syntax redux)

On Mon, Jan 2, 2012 at 3:29 PM, =JeffH <Jeff.Hodges <at> kingsmountain.com> wrote:
> Julian wondered..
>>
>> wouldn't it make sense to have a default for max-age so it
>> can be made OPTIONAL?
>
> hm ... I lean towards keeping max-age as REQUIRED (without a default value)
> and thus hopefully encouraging deployers to think a bit about this and its
> ramifications, and also because its value is so site-specific in terms of a
> web application's needs, deployment approach, and tolerance for downside
> risk of breaking itself.

Makes sense to me.  Chrome currently ignores the header if the server
doesn't specify a max-age.

Adam
websec issue tracker | 3 Jan 03:50 2012
Picon

#33: HSTS: quoted-string grammar in (extension) directives ?

#33: HSTS: quoted-string grammar in (extension) directives ?

 (extension) directives are defined having this grammar..

   token [ "=" ( token | quoted-string ) ]

 There is an argument against having quoted-string as part of the grammar.
 Justification is presented primarily in these messages..

   https://www.ietf.org/mail-archive/web/websec/current/msg00781.html (Adam
 Barth)

   https://www.ietf.org/mail-archive/web/websec/current/msg00920.html (Adam
 Barth)

 ..but also in other messages in the same thread. Nominal summary of
 argument against inclusion of quoted-string is..

  * presently-defined STS header directives don't employ quoted-string
 syntax
  * supporting use of quoted-string syntax raises questions of handling
 error conditions such as
    unbalanced quotation marks.
  * present HSTS implementations don't parse quoted-string STS directive
 values (e.g. max-age="13425")

 Argument for having quoted-string as a part of the grammar is..

  * centered around HTTP header field consistency -- the generic header
 field syntax in RFC2616 (as well as in the in-progress httpbis update)
(Continue reading)

websec issue tracker | 3 Jan 03:55 2012
Picon

Re: #27: HSTS header ABNF is a hybrid of RFC2616 and httpbis and is overly complex and broken

#27: HSTS header ABNF is a hybrid of  RFC2616 and httpbis and is overly complex
and broken

Comment (by jeff.hodges <at> …):

 The portion of Julian's feedback, as identified in
 <http://trac.tools.ietf.org/wg/websec/trac/ticket/27#comment:1> (above)
 that pertains to quoted-string grammar, is now forked off into this
 separate issue ticket #33..

 http://trac.tools.ietf.org/wg/websec/trac/ticket/33

 The other portions of his comments are still under this ticket at this
 time (see any comments below for any changes)

--

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-websec-strict-
  jeff.hodges <at> …          |  transport-sec <at> …
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  strict-      |     Version:
  transport-sec          |  Resolution:
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/websec/trac/ticket/27#comment:2>
websec <http://tools.ietf.org/websec/>

(Continue reading)

Yoav Nir | 3 Jan 07:26 2012
Picon

Re: default value for max-age ? (was: Re: Strict-Transport-Security syntax redux)

On Jan 3, 2012, at 1:29 AM, =JeffH wrote:

> Julian wondered..
>> 
>> wouldn't it make sense to have a default for max-age so it
>> can be made OPTIONAL?
> 
> hm ... I lean towards keeping max-age as REQUIRED (without a default value) and 
> thus hopefully encouraging deployers to think a bit about this and its 
> ramifications, and also because its value is so site-specific in terms of a web 
> application's needs, deployment approach, and tolerance for downside risk of 
> breaking itself.

I tend to agree, but it's not deployers who are going to do the thinking - it's the implementers of web
servers. 

So somewhere, in some control panel for IIS, or a config file for Apache, or some WebUI for some SSL-VPN,
there's going to be a configuration to turn on HSTS, and that product is going to have a default max-age. The
deployers are just going to check the box.

I think we should provide guidance for those implementers as to what is a good default there.

Yoav
Julian Reschke | 3 Jan 09:20 2012
Picon
Picon

Re: default value for max-age ? (was: Re: Strict-Transport-Security syntax redux)

On 2012-01-03 01:50, Adam Barth wrote:
> On Mon, Jan 2, 2012 at 3:29 PM, =JeffH<Jeff.Hodges <at> kingsmountain.com>  wrote:
>> Julian wondered..
>>>
>>> wouldn't it make sense to have a default for max-age so it
>>> can be made OPTIONAL?
>>
>> hm ... I lean towards keeping max-age as REQUIRED (without a default value)
>> and thus hopefully encouraging deployers to think a bit about this and its
>> ramifications, and also because its value is so site-specific in terms of a
>> web application's needs, deployment approach, and tolerance for downside
>> risk of breaking itself.

Understood. I just wanted to make sure that the simplification was 
considered.

> Makes sense to me.  Chrome currently ignores the header if the server
> doesn't specify a max-age.

Well yes, the spec says that it's invalid.

Best regards, Julian
Julian Reschke | 3 Jan 09:22 2012
Picon
Picon

Re: default value for max-age ? (was: Re: Strict-Transport-Security syntax redux)

On 2012-01-03 07:26, Yoav Nir wrote:
> On Jan 3, 2012, at 1:29 AM, =JeffH wrote:
>
>> Julian wondered..
>>>
>>> wouldn't it make sense to have a default for max-age so it
>>> can be made OPTIONAL?
>>
>> hm ... I lean towards keeping max-age as REQUIRED (without a default value) and
>> thus hopefully encouraging deployers to think a bit about this and its
>> ramifications, and also because its value is so site-specific in terms of a web
>> application's needs, deployment approach, and tolerance for downside risk of
>> breaking itself.
>
> I tend to agree, but it's not deployers who are going to do the thinking - it's the implementers of web servers.
>
> So somewhere, in some control panel for IIS, or a config file for Apache, or some WebUI for some SSL-VPN,
there's going to be a configuration to turn on HSTS, and that product is going to have a default max-age. The
deployers are just going to check the box.
>
> I think we should provide guidance for those implementers as to what is a good default there.
> ...

If we know a good default then it should be the default on the wire 
(IMHO). It would help getting predictable behavior when it's missing. 
(Right now the spec allows recipients to do anything they want then it's 
missing, right?)

Best regards, Julian
(Continue reading)

Adam Barth | 3 Jan 10:14 2012

Re: default value for max-age ? (was: Re: Strict-Transport-Security syntax redux)

On Tue, Jan 3, 2012 at 12:22 AM, Julian Reschke <julian.reschke <at> gmx.de> wrote:
> On 2012-01-03 07:26, Yoav Nir wrote:
>>
>> On Jan 3, 2012, at 1:29 AM, =JeffH wrote:
>>
>>> Julian wondered..
>>>>
>>>>
>>>> wouldn't it make sense to have a default for max-age so it
>>>> can be made OPTIONAL?
>>>
>>>
>>> hm ... I lean towards keeping max-age as REQUIRED (without a default
>>> value) and
>>> thus hopefully encouraging deployers to think a bit about this and its
>>> ramifications, and also because its value is so site-specific in terms of
>>> a web
>>> application's needs, deployment approach, and tolerance for downside risk
>>> of
>>> breaking itself.
>>
>>
>> I tend to agree, but it's not deployers who are going to do the thinking -
>> it's the implementers of web servers.
>>
>> So somewhere, in some control panel for IIS, or a config file for Apache,
>> or some WebUI for some SSL-VPN, there's going to be a configuration to turn
>> on HSTS, and that product is going to have a default max-age. The deployers
>> are just going to check the box.
>>
(Continue reading)

Julian Reschke | 3 Jan 10:59 2012
Picon
Picon

Re: default value for max-age ?

On 2012-01-03 10:14, Adam Barth wrote:
> ...
> We should define the behavior in any case, which I guess means I'm
> advocating an default max-age of zero.
> ...

That sounds good to me; so the grammar wouldn't need to enforce this, 
but the effect would be the same.

Best regards, Julian

Gmane