Abstract
Point out the potential for denial of service by duplicating others' atom:id values.
Status
New
Rationale
-
We want atom:id to be univerally unique to a particular entry resource.
-
However, depending on such uniqueness could lead to denial of service attacks where the attacker publishes an entry with an atom:id value used by someone else.
-
Restricting the uniqueness scope of atom:id entirely to a single feed would make it much less valuable, since entries are often copied form feed to feed, and sometimes simultaneously published in multiple feeds.
-
Only requiring entries with the same atom:id to be considered the same if coming from the same feed, but allowing the consuming application to exercize judgement with respect to entries originating in different feeds is a much better match with reality.
-
Still, pointing out the potential for DOS attacks in the Security Considerations section may be preferable to loosening the scope of atom:id uniqueness elsewhere in the spec in either of the ways describe by the preceding bullet points.
Proposal
Add the following to format-08:
8.5 Denial of Service Attacks
Atom Processors should be aware of the potential for denial of service attacks where the attacker publishes an atom:entry with the atom:id value of an entry from another feed, and perhaps with a falsified atom:source element duplicating the atom:id of the other feed. Atom Processors which, for example, suppress display of duplicate entries by displaying only one entry with a particular atom:id value or combination of atom:id and atom:updated values, might also take steps to determine whether the entries originated from the same publisher before considering them to be duplicates.
Impacts
Notes
An alternative to PaceDuplicateIdsEntryOrigin