Re: qconfirm and SRS

On Aug 16, 2004, at 11:46 AM, Toby Betts wrote:
> Jeremy Kitchen wrote:
>> They have to figure out on their own how broken it is, I guess.
>
> I'm a little unclear on how this breaks qconfirm. SRS is supposed to be
> tracable: each step can be reversed, each forward unwrapped like the
> layers of an onion, so that a bounce message can be properly returned 
> to
> the original sender.

I'm interested if Jeremy wants to elaborate; I haven't kept tabs on SRS 
since the original, highly broken version was proposed. It was clear 
enough then that this was a case of security software being designed by 
someone who doesn't know security.

Anyway, the immediate problem is that qconfirm looks at the envelope 
sender, which is munged in a way which changes with each message (using 
a cookie that changes, at least theoretically providing authentication 
and preventing replay attacks). As a result, every message has a new, 
previously unseen sender.

While it's theoretically possible to reverse-engineer the sender 
information, I'm reluctant to waste a lot of effort in that direction, 
particularly if it's already been done. Having done so, of course, it 
becomes impossible to detect spoofed return addresses, which was 
exactly the situation all along. (Lack of public signatures with which 
to verify previous hops is of course a minor misfeature in SRS.)

--Len.