[NNTP] STREAMING diffs (take 2)

[Ken Murchison]

Jeffrey M. Vinocur wrote:

> On Jun 13, 2005, at 2:27 PM, Ken Murchison wrote:
> 
>> Russ Allbery wrote:
>>
>>> Same here.  I don't understand.  Surely the use of deferrals and the
>>> interaction between CHECK and TAKETHIS are protocol issues?
>>
>>
>> The vulnerability that we're discussing isn't inherent in the design 
>> of the CHECK command.  Its only present in server implementations 
>> which choose to "lock" a particular message-id that it receives from a 
>> CHECK command.  You can certainly write a server which isn't subject 
>> to this attack.
> 
> 
> I agree with Russ.  The concept of "locking" is inherent in the 
> protocol; what is the purpose of the 431 response otherwise?

I don't see how anyone reading our document for the first time would 
necessarily think that locking is inherent in the protocol.  In fact, if 
we said that the server SHOULD/MUST do some kind of locking, we'd 
definitely be getting too involved in implementation details and I'd object.

The 431 response could mean any number of things.  It could mean that 
the database which keeps track of message-ids, is temporarily offline, 
or it has too many outdtanding transactions, or too many concurrent 
connections, etc.  I don't see where its "only" meaning is that "we've 
already seen this message-id via IHAVE/CHECK, but haven't received the 
article yet".

That being said, as evidenced by my alternate suggested text, I'm 
convinced that saying something in the security considerations is 
worthwhile as long as we don't make it too implementation specific.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp