On Sunday, October 19, 2003 12:31:12 +0200 Markus Friedl <markus%openbsd.org@localhost> wrote:
On Sat, Oct 18, 2003 at 06:23:25PM -0400, Jeffrey Hutzelman wrote:More application data may be sent after the SSH_MSG_NEWKEYS packet has been sent; key exchange does not affect the protocols that lie above the SSH transport layer. That last sentence is _extremely_ ambiguous. It could be read to mean the behaviour which Markus described, in which application data (and, in fact, anything above the transport layer) is simply suspended until rekeying is complete. Or, it could be read to mean that application data continues to flow during the rekey. I think if I were a new SSH implementor, working in a vacuum, I'd read it to mean that higher-layer protocols are _not_ suspended. So if that's not what we mean, then maybe this needs to bebut that could result in the higher layer using the old keying material forever.
Yes, it does. Of course, that would also happen if neither side decided to do a rekey. Once one side starts a rekey, it could certainly _choose_ not to send any application data until it sends a SSH_MSG_NEWKEYS. But as I read the document, it should be prepared to continue to receive application data using the old keys more or less indefinitely. This isn't an interop problem; it just means that one side can choose never to take new keys into use and instead continue to use the old keys for "too long".
That said, I'm not actually advocating either behaviour over the other. However, I do think the document needs clarification in this regard. I've been active in this working group for a while now; I've written the specification for a key exchange method, and reviewed a special-purpose host key algorithm which depends on behaviour during a rekey. Until this discussion started, I believed the spec permitted higher-layer protocols to continue during a rekey. If I made that mistake, I wonder how many implementors also did.
clarified. Bleah.I wrote earlier:
Yes, your mail was quite clear on what the behaviour should be. But email isn't good enough; future implementors (and probably even some present ones) are going to work from the spec, not the mailing list discussion.
-- Jeff