Re: IESG feedback on core drafts.

[Eric Rescorla <ekr%rtfm.com@localhost>]

Tero Kivinen <kivinen%iki.fi@localhost> writes:

> > > >    In addition, the CBC mode attack can be mitigated by
> > > >    ensuring the an SSH_MSG_IGNORE packet preceeds any real
> > > >    data at the start of a TCP packet.
> > > A TCP packet? How is the TCP mapping relevant?
> 
> To the attack to work, the attacker needs to know the IV of the next
> block that is going to be encrypted. In CBC that is the output of the
> encryption of the previous block. If the attacker does not have any
> way to see the packet yet (i.e it is in the internal buffers of the
> ssh implementation or even in the kernel) then he cannot use this
> attack. If the last packet has been sent out to the network (i.e
> attacker will know it) then he can use the attack.
>
> 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.

For instance, Consider the following case:

Client                                                  Server
------                                                  ------
TCP(seq=x, len=500)           ->
   contains Record 1 

                    [500 ms passes, no ACK]

TCP(seq=x, len=1000)           ->
   contains Records 1,2 
 
                               <-                        ACK


(1) The Nagle algorithm + TCP retransmits mean that the two
    records get coalesced into a single TCP segment
(2) Record 2 is *not* at the beginning of the TCP segment
    and never will be, since it gets ACKed.
(3) Yet, the attack is possible because Record 1 has already
    been seen.

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.

On the other hand, it's perfectly safe to have the following
situation:

Client                                                  Server
------                                                  ------
TCP(seq=x, len=500)           ->
   contains SSH_MSG_IGNORE

TCP(seq=y, len=500)           ->
   contains Data

Provided that the IV for second SSH Record is fixed after
the data for the Data packet is determined. I.e. you
do:
        read from user
        encrypt null packet
        encrypt data 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"

-Ekr

-- 
[Eric Rescorla                                   ekr%rtfm.com@localhost]
                http://www.rtfm.com/