James M Snell wrote:
Ignoring the overhead that it adds for now, isn't this the kind of
situation digital signatures are designed to handle?
Yes. Norm and I have mentioned this as well. I do not think we can solve
this problem by patching the Atom level, ensuring that the Atom level
can
On Wednesday, May 25, 2005, at 06:14 PM, James M Snell wrote:
Ignoring the overhead that it adds for now, isn't this the kind of
situation digital signatures are designed to handle?
Sure, but how many publishers are going to be using digital signatures
in the near term (and more importantly,
On Thursday, May 26, 2005, at 08:04 AM, A. Pagaltzis wrote:
* Graham [EMAIL PROTECTED] [2005-05-25 23:00]:
How is this a Denial of service attack? Isn't it just
ordinary spoofing/impersonation?
Indeed; Id like to see this reworded to refer to spoofing, as
thats what it is.
I presume the
Antone Roundy wrote:
On Wednesday, May 25, 2005, at 06:14 PM, James M Snell wrote:
Ignoring the overhead that it adds for now, isn't this the kind of
situation digital signatures are designed to handle?
Sure, but how many publishers are going to be using digital signatures
in the near
On Wednesday, May 25, 2005, at 01:20 PM, Graham wrote:
On 25 May 2005, at 7:35 pm, Antone Roundy wrote:
If multiple atom:entry elements originating in the same Atom feed
have the same atom:id value, whether they exist simultaneously in one
document or in different instances of the feed
On 25 May 2005, at 9:01 pm, Antone Roundy wrote:
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
On Wednesday, May 25, 2005, at 02:49 PM, Graham wrote:
On 25 May 2005, at 9:01 pm, Antone Roundy wrote:
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
On 25 May 2005, at 10:05 pm, Antone Roundy wrote:
But is it not potentially a DOS? The Good Guy publishes an entry.
The Bad Guy copies the atom:id of that entry into an entry with
different content, gives it a later atom:updated, and publishes
it. The aggregator stops
Please forgive me for stepping in here, because of the recent list
volume I've only been able to partially pay attention to this
discussion, but I just wanted to make a quick observation..
Ignoring the overhead that it adds for now, isn't this the kind of
situation digital signatures are
On May 25, 2005, at 1:49 PM, Graham wrote:
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
10 matches
Mail list logo