Re: Security Considerations for Link Extensions

[Bob Wyman <bob@xxxxxxxx>]

I'm a bit worried about a potential "security" concern if people overuse the hash attribute. This is something that really should only be used when you really need to refer to a specific version of a resource -- and it should be a resource that you expect to be stable for a useful period of time. My concern is that people will tend to think that it is "cool" to add in more metadata on links and thus will just hash all kinds of stuff -- because they can. The result will be a large number of "broken" hashes and a sense that since most hashes are broken, the fact that a hash is broken is simply not interesting... At that point, various social engineering operations become possible.

We really should consider discouraging people from using the hash attribute unless it is really necessary and unless they actually expect that the resource they are hashing *should* be stable for a usefully long period of time.

bob wyman

On Tue, May 25, 2010 at 5:06 PM, James Snell <jasnell@xxxxxxxxx> wrote:

I've been considering either an "accessed" attribute or specifying
terms that indicate that atom:updated element be used as the
point-in-time for the links for atom:entry and atom:feed. The when
attribute would serve the same purpose for at:deleted-entry and I
assume that other containers for atom:link could specify their own
relevant time. And you make an excellent point on focusing on the
specific utility of the attributes. Are there are security concerns
you can think of relating to the specific use cases for these
attributes?

On Tue, May 25, 2010 at 12:52 PM, Bob Wyman <bob@xxxxxxxx> wrote:
> The way you describe the utility of the hash, you make it sound like it is
> somehow "inadequate" for the traditional use of hashes. But, that's not
> really relevant here. This is a use of a hash for a different purpose than
> the hashes we normally use in link integrity checking. I would suggest that
> you focus on the utility of this style of hash rather than emphasizing the
> things that it doesn't even attempt to do.
> BTW: I realize that this may be totally unnecessary, however, I can't help
> thinking that a "last-accessed-on" attribute to show when the link was last
> accessed and thus when the hash was generated might be useful... In nothing
> else, there is a good bit of precedence in things like formal standards for
> citing web resources that typically require that a "last-accessed" date be
> provided. I'm not willing to invest a great deal in fighting for this. I
> just thought I would mention it.
> bob wyman
>
> On Tue, May 25, 2010 at 3:07 PM, James Snell <jasnell@xxxxxxxxx> wrote:
>>
>> Ok, so I'm working on finishing up the basic link extensions draft.
>> The Security Considerations are currently TBD. I wanted to take a
>> moment to solicit input on appropriate security considerations for
>> these optional, advisory extension attributes.
>>
>> One in particular... hash digest are often used as a simple means of
>> verifying that data has not been modified while in transit.. hash
>> digests contained within an atom:link cannot be used for that purpose.
>> Rather, the hash attribute is used to express the state of the linked
>> resource at a given point in time so that a feed consumer can detect
>> whether or not the resource has been modified since the link was
>> created.
>>
>> Other than that, there really shouldn't be any further security
>> concerns with regards to the link extensions.. but I welcome being
>> corrected on that :-) Thoughts?
>>
>> --
>> - James Snell
>>  http://www.snellspace.com
>>  jasnell@xxxxxxxxx
>>
>
>

--

- James Snell
 http://www.snellspace.com
 jasnell@xxxxxxxxx