Re: IESG feedback on core drafts.

[Tero Kivinen <kivinen%iki.fi@localhost>]

Eric Rescorla writes:
> > In optimal case we would need to add extra packet only if the packet
> > has been sent out to network, and there is no other packets waiting in
> > any buffers. Unfortunately it is not normally easy to see if there are
> > unsent packets in the kernel, thus for example ssh's secsh checks if
> > there is any data in its own buffers, and if not then it will add
> > extra packet. 
> Yes, I'm familiar with the Rogaway attack, but it's a mistake to
> get fixated on TCP mapping.
... 
> (3) Yet, the attack is possible because Record 1 has already
>     been seen.

Yes, as I say above the important thing is if it has been ever sent
out to network.

> As this example indicates, it's totally unsafe to use the existence
> of unflushed data in the TCP buffers proper as a guide to whether
> you need an empty packet, since when you do the second write(),
> the buffers will contain the un-ACKed Record 1.

It is safe, if and only if you get the information from the TCP stack
if that data at the end of the TCP buffers have ever been sent out to
network. If it has never ever been sent out to network, then we do not
need the extra packet, if it has already been sent out, then you do
need extra packet. 

> The point is that you can't safely talk about TCP packets. If you want
> to talk about conditional empty packet insertion you should talk about
> the data being "written" "delivered to the network"

I think I have been using term "seen on the network" all the time, I
didn't talk about TCP packet. 
-- 
kivinen%ssh.fi@localhost
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/