Re: msgr2 protocol

[Marcus Watts <mwatts@redhat.com>]

If the client doesn't look at "features" before it sends stuff, it
will not be able to be very smart about taking advantage of some
future better method.  In fact, there isn't much advantage
to the server sending anything early - it could just as easily
wait until after it's seen the clients request.

Failing hard & retrying on a failed reconnect is going to be slower.
On the bright side, at least it shouldn't happen often.

If you're sending encryption (w/ different auth or keys) from several
different streams, how are you planning to indicate which bits
go with which scheme?, and which bits are you planning to encrypt
and which not?  

Byte count limits.  Basically, you don't want collisions because
of duplicated keys or data.  This depends on your crypto system,
so, for instance, you should not encrypt with one key more than
	aes, cbc	about 2^68 bytes
	aes, ctr	exactly 2^128 bytes
more generally, this depends on mode, blocksize, ...
This applies across *all* uses of the key - and so you would
generally want to use the session key directly as little as possible.
(in particular, using the session key for ctr directly would be very very bad.)

If you've got multiple streams going already, you should be able
to include a fairly simple rekey method with little effort.
For instance, as part of the method, you could,
	up front as part of the method
		send a per-stream key encrypted under the shared secret.
	prepend to the first data sent in a payload
		byte limit, stream key #0 (encrypted under the per-stream key)
		then encrypt the next N bytes with stream key #0
	when the byte limit is reached, prepend to the
		next data sent in a payload
		byte limit, stream key #1 (encrypted under the per-stream key)
		then encrypt the next N bytes with stream key #1
	&etc.

					-Marcus Watts