Re: Albrecht/Paterson/Watson's attack

>> What benefits _does_ [EtM] provide?  Why do they outweigh exposing
>> packet sizes?
> It eliminates about a decade's worth of assorted oracle attacks on
> encryption algorithms, implementations, packet-handling code, and so
> on.

...replacing them with something with an unknown set of issues, because
it hasn't had a decade-plus of burning in.

> The "not exposing packet sizes" is rather overrated in any case,

Perhaps.  I'm not convinced either way on that.

> unless you go to extraordinary lengths in your implementation all an
> attacker has to do is look at the TCP traffic to see where one packet
> stops and the next one starts.

Even to the extent that the TCP in use reflects write() boundaries as
segment boundaries (which in my limited experience is mostly true under
low load with small writes and usually not under high load or with
large writes), that will give the attacker only some packet boundaries.
That is, segment boundaries will be packet boundaries, but packet
boundaries may not be segment boundaries.

I haven't seen an analysis of the risks of exposing such metadata.  I'm
not competent to do that myself; until someone does do such an
analysis, I'm not going to take it on myself to decide that the
exposure is ignorable.

> In any case apart from sensitive packets like ones containing
> password info (e.g. the userauth messages), which one would hope are
> padded to a fixed size,

They are not, in general - see section 8 of 4252; it does not specify,
nor even recommend, any padding.  Since there is no easy way to set a
maximum on password length on a remote system, it's hard (even aside
from possible internal architecture issues) to pd them to a fixed size.
Implementations certainly could pad if they felt like it; have you
looked to see whether any of the ones you have access to do?  moussh
does not pad password-carrying packets except as required by section 6
of 4253 (which applies to all packets, not just password-carrying
ones).  Indeed, I would be inclined to worry that padding password
packets specially might make them more identifiable on the wire.

> what real, actual benefit (not gedanken-experiment hypothesis) does
> an attacker gain from knowing the packet length?

I don't know; I'm not an attacker.  I do know that I'm not about to
meddle with a crypto protocol without reasonable assurance that it
won't cause trouble, and "a dilettante cryptographer [me] couldn't
describe an exploitable problem with the new protocol offhand" is not
good enough assurance.

> My guess is that most (all?) SSH implementations have been exposing
> packet lengths (at the TCP level) for more than a decade without
> anyone being able to exploit it.

Er, not quite.  "without anyone exploiting it" != "without anyone being
able to exploit it".  (Furthermore, "without anyone exploiting it" !=
"without your hearing of anyone exploiting it", but since I don't know
how well-placed you might be to hear of such things, I'm willing to
plead nolo contendere on that point.)  Also, as I outlined above, I'm
far from convinced that exposing TCP packet boundaries is equivalent to
exposing packet lengths.

Also, "more than a decade"?  The SSH RFCs are dated January 2006, so
presumably you are including SSHv1 - what are the differences at these
levels of its protocol?  I've never seen documentation on its protocol
other than the code, and I've never been motivated enough to
reverse-engineer the protocol documentation from the code.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B