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
