headers
=JeffH | 3 Jan 2012 00:29

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
Permalink | Reply | 9 comments |
headers
Chris Palmer | 3 Jan 2012 01:35
Picon
Favicon

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.
Permalink | Reply | 0 comments |
headers
Adam Barth | 3 Jan 2012 01:50

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
Permalink | Reply | 1 comment |
headers
websec issue tracker | 3 Jan 2012 03:50
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)

Permalink | Reply | 7 comments |
headers
websec issue tracker | 3 Jan 2012 03:55
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)

Permalink | Reply | 0 comments |
headers
Yoav Nir | 3 Jan 2012 07:26
Picon
Favicon

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
Permalink | Reply | 4 comments |
headers
Julian Reschke | 3 Jan 2012 09:20
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
Permalink | Reply | 0 comments |
headers
Julian Reschke | 3 Jan 2012 09:22
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)

Permalink | Reply | 3 comments |
headers
Adam Barth | 3 Jan 2012 10:14

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)

Permalink | Reply | 1 comment |
headers
Julian Reschke | 3 Jan 2012 10:59
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
Permalink | Reply | 0 comments |

Gmane