Security Considerations for Link Extensions

[James Snell]

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?

[Bob Wyman]

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

Post by James Snell
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

[James Snell]

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?

Post by Bob Wyman
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

Post by James Snell
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

[Bob Wyman]

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

Post by James Snell
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?

Post by Bob Wyman
The way you describe the utility of the hash, you make it sound like it

is

Post by Bob Wyman
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

Post by Bob Wyman
the hashes we normally use in link integrity checking. I would suggest

that

Post by Bob Wyman
you focus on the utility of this style of hash rather than emphasizing

the

Post by Bob Wyman
things that it doesn't even attempt to do.
BTW: I realize that this may be totally unnecessary, however, I can't

help

Post by Bob Wyman
thinking that a "last-accessed-on" attribute to show when the link was

last

Post by Bob Wyman
accessed and thus when the hash was generated might be useful... In

nothing

Post by Bob Wyman
else, there is a good bit of precedence in things like formal standards

for

Post by Bob Wyman
citing web resources that typically require that a "last-accessed" date

be

Post by Bob Wyman
provided. I'm not willing to invest a great deal in fighting for this. I
just thought I would mention it.
bob wyman

Post by James Snell
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

--
- James Snell
http://www.snellspace.com

[James Snell]

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

Post by Bob Wyman
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

Post by James Snell
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?

Post by Bob Wyman
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

Post by James Snell
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

--
- James Snell
 http://www.snellspace.com

[Colm Divilly]

Post by James Snell
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.

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 ?

Post by James Snell
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?