Thanks Alex. A session is indeed a session, and everyone tends to build and use sessions in the same way, with a single key (and as mentioned earlier, sometimes a key renegotiation phase). And of course, in practice no-one 'breaks' encryption, they just find ways around the implementation.
However, what differs SSP/mosh and the other examples you raise is the existence of a fixed source IP address and a TCP session around the application session. SSP/mosh has uniquely rejected any privilege for the source IP. Also, when you say that SSH is providing 'authentication', it isn't providing this over the full duration of the mosh session - it's providing authorization to start the mosh-server, and a channel to communicate the key. -jim ________________________________________ From: Alex Chernyakhovsky [acher...@mit.edu] Sent: Thursday, 2 January 2014 5:32 p.m. To: Jim Cheetham Cc: Keith Winstein; mosh-users; mosh-devel@mit.edu Subject: Re: [mosh-devel] [mosh-users] Logging from mosh-server > you're using only a single factor to represent permission to connect to a > server I'd like to point out that this is basically true of both SSH (encrypt-then-MAC) as well as TLS (MAC-then-encrypt); you're just using two separate secrets negotiated with the server because each algorithm (encrypt, MAC) needs its own keys. In the event of client compromise, all of the necessary information to hijack the connection is compromised regardless of the mode. Utilizing SSH for authentication *allows* mosh to rely on existing multi-factor authentication schemes without any modification. Sincerely, -Alex On Wed, Jan 1, 2014 at 11:06 PM, Jim Cheetham <jim.cheet...@otago.ac.nz> wrote: > From: winst...@gmail.com [winst...@gmail.com] on behalf of Keith Winstein > [kei...@mit.edu] > Sent: Tuesday, 31 December 2013 8:47 p.m. >> I'd be happy to participate on IRC if you think that would be helpful -- >> just let me know the date/time. > > Currently I'm on at 13:20 WST (Perth, Australia) on Thursday 9 Jan. I don't > know your timezone, but that'll be between 9pm and midnight on *Wednesday* > for the US > (http://www.timeanddate.com/worldclock/fixedtime.html?msg=lca2014mosh&iso=20140109T13&p1=196). > If you could start up a new IRC channel for this, I'll pop it up onscreen > during the Q&A. > > >> From a cryptographic perspective, Mosh (with its pinned AEAD mode) is >> probably better than SSH's encrypt-and-MAC and also better than TLS's >> MAC-then-encrypt. > > What makes me uncomfortable at the moment is that if feels like you're using > only a single factor to represent permission to connect to a server (the UDP > port and sequence numbers seem to be too public to count as reliable > factors), whereas traditionally we spend time on > multi-factor-authentication. It's a handwave to say that you defer to ssh > for authentication, because that's only true for starting the server; at > every point after that your key represents full authentication. Everyone > else's session keys are tied up with the TCP source, which isn't the > strongest factor in the world but is better than nothing. > > However, just because I'm uncomfortable with it doesn't mean I'm right :-) > In order to have a proper argument with you about the datagram layer, I'm > going to have to do a lot of research & learning (or convince some people I > know who already know this stuff to do it for me!). > >> You're right that a bad guy who steals the session key from a mobile >> device can "roam" the session elsewhere. Compromise of the client is a >> difficult attack to counteract. > > Compromise of the client device is basically undetectable *by the client*; > in general when we look at security from a higher level we are profiling > behaviour between systems and looking for that to change. The server is the > best-qualified point at which to manage this sort of thing (not least > because the server can decrypt the packets), which is one reason why more > logging will help tremendously. Perhaps having the logging policy in an /etc > file would help people to set a local 'default' nicely, without end-users > having to remember to invoke it every time. > > -jim > > > _______________________________________________ > mosh-devel mailing list > mosh-devel@mit.edu > http://mailman.mit.edu/mailman/listinfo/mosh-devel > _______________________________________________ mosh-devel mailing list mosh-devel@mit.edu http://mailman.mit.edu/mailman/listinfo/mosh-devel
