Subject: Security Considerations for Link Extensions

From: James Snell <[email-masked]>
Date: Tue, 25 May 2010 12:07:37 -0700

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
  [email-masked]

---

From: Bob Wyman <[email-masked]>
Date: Tue, 25 May 2010 15:52:34 -0400

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

---

From: Colm Divilly <[email-masked]>
Date: Tue, 25 May 2010 21:25:43 +0100

> whether or not the resource has been modified since the link was
That sounds more like an Entity Tag (which are often but not always 
generated using hashes),  so  do we  really mean an Entity Tag or is 
there a reason to restrict this to just using hashes ?

---

From: James Snell <[email-masked]>
Date: Tue, 25 May 2010 14:06:01 -0700

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?

---

From: Bob Wyman <[email-masked]>
Date: Tue, 25 May 2010 19:29:55 -0400

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

---

From: James Snell <[email-masked]>
Date: Tue, 25 May 2010 16:36:09 -0700

Sounds good.. interested in working up some text for that ;-)