Re: ID for Immutable

On 29/10/2016 6:21 a.m., Patrick McManus wrote:
> I do believe the lack of integrity protection in plaintext transfer is an
> important security consideration for immutable that suggests they should
> not be used together. I'm open to other wording on it for sure.. https://
> might be sufficient here.
> 

Since the behaviour which 'immutable' is defining is already optionally
followed by any cache implementation in both insecure and secure
contexts. There is no additional security considerations being added by
this option.

The security considerations around corrupt objects being considered
"fresh" applies to HTTP caching in general, not just immutable objects.

The issues that are being pointed out are real, but apply equally for
secure and for insecure contexts already today without immutable being
involved. I dont see any need to distinguish between contexts in this
draft, nor to prohibit 'insecure' contexts from having immutable objects.


To back this; Squid has for a very long time had a configuration control
which enables admin to mark specific URL as having this same immutable
behaviour. It is one of the more popular ones and used in the 'insecure
context'.

AFAIK, the only issue which has come to light in all that time that can
be attributed to this control is that objects changing faster than what
the admin was aware (or their stated expiry time) had to be manually
refreshed from the client end (if anyone actually cared). Moving the
control point from proxy config to origin server avoids that issue.

Amos

Received on Sunday, 30 October 2016 03:16:08 UTC