Re: draft minutes from meeting at ietf50..

[Mika Kojo <mkojo%ssh.com@localhost>]

Tom, 

I suppose that the question should be

 Q: How could the leakage of information in interactive sessions be 
    made negligible?

If such an improvement exists then (interesting) traffic analysis
becomes impossible as a consequence.

My answer would currently be: there is no such (practical)
improvement. The only robust improvement that I know would require
non-negligible increase in traffic.

Naturally this suggests that the problem is not the protocol. Infact,
SRP is not a protocol fix---it fixes only those applications(*) that
are aware of this feature. Similar effect would be obtained by having
a specific password packet that holds the password in its entirety,
rather than sending it in pieces.

(*) I consider everything above the transportation layer as an
    "application" of the protocol. Sorry for abuse of terminology.

As you suggest it is possible by careful use and implementation of the
applications to make sure that important information is not leaked.

Mika Kojo
SSH Communications Security Corp

Tom Holroyd writes:
> On Sat, 21 Apr 2001, Markus Friedl wrote:
> 
> > On Sat, Apr 21, 2001 at 03:50:10PM +0900, Tom Holroyd wrote:
> > > On Fri, 20 Apr 2001, Niels Provos wrote:
> > >
> > > > An adversary can listen to SSH network traffic to determine the length
> > > > of authentication passwords typed during login and interactive shell
> > > > sessions [B].
> > >
> > > Of course SRP authentication fixes that...  The SRP shared secret can also
> > > be used to trigger a key-reexchange, which makes shorter DH parameters
> > > less of a problem.
> >
> > i don't see how SRP makes traffic analysis harder.
> >
> > could you please provide details.
> 
> The SRP password is never sent over the network, only some random bignums
> of known length, and some hashes, also of known length.  So even if you
> can observe traffic you can't get the length of the password/phrase.
> 
> OTOH, if you ssh to host A, and then from host A ssh to host B, your
> password will be sent over the (encrypted) link from your client to A, so
> that may leak password length information.  That can be fixed by running
> ssh from your client and either connecting directly to B, or if that's not
> possible, forwarding the connection through A (instead of running ssh on
> A).
> 
> Dr. Tom Holroyd
> "I am, as I said, inspired by the biological phenomena in which
> chemical forces are used in repetitious fashion to produce all
> kinds of weird effects (one of which is the author)."
> 	-- Richard Feynman, _There's Plenty of Room at the Bottom_
>