Yoav Nir said..
>
> 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.
Yep, very good point, thanks.
Adam Barth replied..
>
> On Tue, Jan 3, 2012 at 12:22 AM, Julian Reschke <[email protected]> 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.
>>>
>>> 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?)
>
> We should define the behavior in any case, which I guess means I'm
> advocating an default max-age of zero.
Julian followed up..
>
> That sounds good to me; so the grammar wouldn't need to enforce this,
> but the effect would be the same.
sounds fine to me too.
I have text in my working copy in (newly numbered section) "10.1. HSTS Policy
expiration time considerations" addressing the above.
And so did Tobias..
>
> well, the optimal default may actually be depending on the host.
> So we might want to describe what good values might be under which
> circumstances.
> E.g. long time-spans when using very trusted process and provider,
> shorter time-spans with less capable / higher risk of bricking yourself
> / loosing your private key / ...
Yes, i've been thinking about such language and will add a stab at it to
section 10.1.
=JeffH
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
