Subject: cache invalidation and "denial of service" [was: WGLC #363: rare cases]

From: Mark Nottingham <[email-masked]>
Date: Tue, 3 Jul 2012 12:16:53 +1000

I see what you're saying. I wouldn't resist removing that sentence. Anybody that would?

Regards,

On 27/06/2012, at 10:00 PM, John Sullivan wrote:

> Mark Nottingham wrote:
>> Those are reasons not to generate a LM, but they aren't specific to HTTP/1.0 -- agreed?
> 
> Sure.
> 
>> I can see dropping the last sentence and qualifying the remaining SHOULD with these sorts of reasons, but not retaining it.
> 
> Absolutely - explain, not ignore or gloss over.
> 
> There's actually another bit which does much the same thing  that
> I've got on my list of quibbles:
> 
> RFC 2616 S13.10
> 
>   In order to prevent denial of service attacks, an invalidation based
>   on the URI in a Location or Content-Location header MUST only be
>   performed if the host part is the same as in the Request-URI.
> 
> httpbis-p6-cache S2.6
> 
>   However, a cache MUST NOT invalidate a URI from a Location or
>   Content-Location response header field if the host part of that URI
>   differs from the host part in the effective request URI (Section 5.5
>   of [Part1]).  This helps prevent denial of service attacks.
> 
> It's never fully explained how such a denial of service attack would
> manifest, nor how serious it could be. The immediate possibility is
> being able to effectively clear a cache causing more load on the
> origin that usual, or more transit from the cache than usual, but I
> have difficulty seeing how that is a serious concern:
> 
> This basically requires a malicious origin to work. If the cache is
> inside the control of the origin, then presumably the origin isn't
> malicious.
> 
> If the cache is outside the control of the origin, then if the target
> is a different origin it presumably has to be able to deal with
> a reasonable level of uncached requests hitting it anyway. If the
> target is the cache itself then (without the vhost check) we can
> clear at most 2 unrelated URLs per incoming client request. But a
> client could clear those URLs anyway by sending max-age=0 and dropping
> the connection after the first body byte. This will cause many
> implementations to drop the previously cached response and cease
> storing the new one too.
> 
> So I don't see how malicious use of Location/Content-Location is
> much worse than other techniques, and it's arguably harder to pull
> off than a purely client driven attack.
> 
> I'm not suggesting dropping the vhost check here, it seems like a
> reasonable idea, but the justification seems overblown.
> 
> John
> -- 

--
Mark Nottingham   http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 3 Jul 2012 12:24:18 +1000

Wrapping this up: I haven't heard any objection to removing this sentence from P6:

"In those rare cases where the use of a Last-Modified value as a validator by an HTTP/1.0 system could result in a serious problem, then HTTP/1.1 origin servers SHOULD NOT provide one."

So I'm scheduling for the next draft.

Cheers,

On 27/06/2012, at 2:01 PM, Mark Nottingham wrote:

> 
> On 27/06/2012, at 12:32 PM, Amos Jeffries wrote:
> 
>> On 27.06.2012 11:22, Mark Nottingham wrote:
>>> On 27/06/2012, at 1:22 AM, John Sullivan wrote:
>>> 
>>>> Mark Nottingham wrote:
>>>>> Now <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/363>.
>>>>> 
>>>>> 
>>>>> On 23/06/2012, at 9:28 PM, Julian Reschke wrote:
>>>>> 
>>>>>>> "HTTP/1.0 clients and caches might ignore entity-tags. Generally, last-modified values received or used by these systems will support transparent and efficient caching, and so HTTP/1.1 origin servers SHOULD provide Last-Modified values. In those rare cases where the use of a Last-Modified value as a validator by an HTTP/1.0 system could result in a serious problem, then HTTP/1.1 origin servers SHOULD NOT provide one."
>>>>>>> 
>>>>>>> DESIGN - What are the "rare cases" being talked about here, and how are servers supposed to detect them?
>>>>>> 
>>>>>> Good question. We may want to drop this.
>>>> 
>>>> 1) Algorithmically generated output where ETag can represent the
>>>> current control or seed values directly, but generating Last-Modified
>>>> would require extra persistent storage.
>>>> 
>>>> 1b) Resources gatewayed from systems that have no concept of
>>>> last-modification time, but ETag along with the URL can again
>>>> represent parameters that are guaranteed to retrieve the same
>>>> entity or detect a change/error.
>>>> 
>>>> 2) Rapidly changing, but cacheable, resources, where the origin knows
>>>> that Last-Modified could never become strong by S13.3.3. Normally
>>>> harmless but pointless.
>> 
>> This bit ...
>> 
>>>> If it suspects that a downstream would
>>>> wrongly use the weak Last-Modified where it shouldn't, then it might
>>>> want to avoid that dangerous possibility altogether.
>> 
>> ... seems to be repeating the "rare cases" clause. Again with no supporting evidence for its existence, or identifiable way the origin might know about *future* downstream caching decisions.
>> 
>> 
>> To me the clause looks like dependence on the "evil bit" or equivalent being sent.
>> 
>> 
>> Although if the request was sent with a Date: which was noticeably out of sync with the servers own clock or some IMS timestamp in the future. Those could be a sign that the downstream is not able to depend on timestamps like LM properly. But I wouldn't bet on that either with the clockless algorithms.
>> 
>> 
>> Drawing at straws here it may be referring to the (hopefully rare) case of a server being required to add a Date: to a response with Last-Modified already in place? (ie CGI script created hedes being processed by an origin).
>> In that case would it be better to add the Date and drop the Last-Modified? or simply not add the Date? (violating part 2 section 10.2)
> 
> 
> I think this is getting into error-handling territory (inside the same implementation!).
> 
> I think we should just remove the last sentence. We already contextualise it:
> 
> """
> Origin servers SHOULD send Last-Modified for any selected representation for which a last modification date can be reasonably and consistently determined...
> """
> 
> Cheers,
> 
> 
> --

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Jul 2012 09:11:35 +0200

On 2012-07-03 04:16, Mark Nottingham wrote:
> ...

Works for me.

Change applied with 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1703>.

Best regards, Julian