[tahoe-dev] [tahoe-lafs] #958: LAFS 301 Moved Permanently

[Kyle Markley]

On Thu, 05 Aug 2010 12:04:25 +1000, "James A. Donald" <jamesd at echeque.com>
wrote:
> On 2010-08-04 4:06 AM, tahoe-lafs wrote:
>>   Hm, would it be okay to allow people to set an HTTP 301 to a
different
>>   cap
>>   of a different ''type'', such as a read-write cap instead of a
>>   read-only
>>   cap or a read-only cap instead of a read-write cap?
>>
>>   Our tradition of transitive attenuation of authority suggests that we
>>   should forbid this, which means that a client which is ''following''
an
>>   HTTP 301 redirect should remember whatever the attenuation of the
>>   original
>>   cap was (i.e. if it was read-only or ''???'' if it was a verify-only
>>   cap)
>>   and refuse to use the new cap with authority outside of that.
> 
> Obviously the person who sets up a 301 to greater authority *has* that 
> authority - so he should be able to share that authority with who he 
> chooses.

I'm not a security expert but I'm puzzled by the idea of attenuating the
authority.  Surely it can't be the client's job to implement this
attenuation; it's easy to modify the client source code to skip any
locally-performed attenuation and let the stronger cap flow through.  This
could be done in the server only if the server is known to be
un-tampered-with.

I think I'm with James.  The person who set up the redirect is responsible
for the consequences of it.  But if we really wanted to attenuate the new
cap, I think we'd have to do it at the time the redirect is created, not
when it's accessed.  The creator's client code (which they trust) would
have to downgrade the cap so that the stronger cap is never sent to the
storage nodes at all.  The stronger cap isn't there, so no local source
code changes by an attacker could possibly reveal it.

-- 
Kyle Markley