Wandering Thoughts archives

A SMTP implementor's conundrum

Today I ran across a good example of the sort of engineering conundrum that bedevils people who implement things like SMTP clients:

In a multiline SMTP reply, which reply code should you use if different lines of the reply have different codes?

That is, in a regrettably non-hypothetical example, if you send a server 'MAIL FROM:<something>' and get back:

250-There's a problem.
454 please try later

Should your client go on and send a RCPT TO, go away to try again later, or just run screaming?

(Sending such a multiline reply is not spec compliant, but our core mailer is held together by bailing wire and chewing gum, so these things surface every so often.)

RFC 2821 is silent on this, unsurprisingly. Our usual MTA and all the code I've had a hand in has used the last line's reply code, and I've been assuming that that's how everyone operated. But today I found out that Exim appears to use the first line's reply code instead, and so thinks that its MAIL FROM was accepted.

(Then when Exim goes on to send a RCPT TO, the server sees it as an out of phase command, which is a 5xx hard error and Exim bounces the message. I think they were all spam messages, so I'm not too broken up about this.)

I think our choice of using the last line's reply code makes more sense (and is more likely to be the server's intention). But I can't exactly blame Exim for its decision, and I have to admit that I'm biased.

Why I don't expect result-oriented work hours to work out

A recent Slashdot story pointed to this article on one company's more flexible approach to work hours. It has the line:

The goal at Best Buy is to judge performance on output instead of hours.

My immediate cynical reaction is that this is a marvelous theory but doomed in most practices. The root problem is the same seductive thought in management that leads to excessive overtime: 'if my employee is getting all this done in N hours now, think how much more work she could do in N+Y hours!'

Or in other words, if employees have idle time you're clearly not working them hard enough. ('Giving them enough work' is the more polite but less brutally honest version.)

(I suppose that ultimately this is a variant of Brooks' Law, in that it is management treating all hours of work as equivalent when they aren't. In Brooks' Law the additional hours come from new people instead of existing people, but the core mistake is the same.)

One ultimate end point of this whole idea is a pattern we've already seen: piece-work, where people are paid by the result. Interestingly, I understand that auto mechanics often work this way; there is a fixed charge for many repairs, based on the nominal time it should take, and a skilled mechanic who can do them faster than average can benefit significantly. (Applications to system administration are left as an exercise.)

How SSH achieves forward secrecy

A while back a co-worker asked me why SSH (sometimes) uses a second temporary host key in addition to the main host key. I had to think about it for a bit: it's to keep the session private even if the server's host key is later compromised.

(The clever person will notice I could have found this out just by reading the description of the KeyRegenerationInterval sshd parameter. I observe that one rarely pauses to grovel through manpages when discussing half-remembered things with co-workers.)

Public key cryptography is too computationally expensive to do all the time, so SSH sessions are actually encrypted with a random symmetric key; arranging the session key is more or less the only thing done with actual public key cryptography.

(This is common to pretty much every encryption protocol that uses public key cryptography; SSL and even GPG-encrypted email work this way.)

However, if the session key was encrypted with the server's normal host key, there's a problem. An attacker could record a boatload of SSH sessions, then later compromise the server, get its host key, use the host key to decrypt the initial protocol exchange for each session (imitating what the server did during the actual sessions), recover each session key, and decrypted all of those recorded SSH sessions at their leisure.

Preventing this attack is called having perfect forward secrecy.

In version 1 of the SSH protocol, PFS is achieved by using the second, ephemeral set of host keys. The session key is actually encrypted with these ephemeral keys, not directly with the permanent host key, and then the ephemeral keys are discarded every so often. (They could be discarded after every connection, but generating new ones is pretty expensive.)

As the sshd_config manpage mentions in passing, though, this only applies to version 1 of the SSH protocol. So how does SSH v2 achieve (perfect) forward security?

It turns out that the answer is in RFC 4251's section 9.3.7: SSH v2 normally uses Diffie-Hellman key exchange to set up the session keys, which inherently provides perfect forward security without needing a second set of host keys or anything like that. In fact it does it better than SSH v1, because SSH v2 destroys the information that would compromise the session key immediately after generating it, instead of some time later.

(This is one of those entries that I write partly to explain all this to myself, and partly because I had to go digging in RFC 4251 to find the explanation for SSH v2 so I might as well share.)