I am concerned about the implications of an encryption algorithm spec changing parts of the base protocol.I'm not sure that's really what's going on here. I really need to find the time to go read the spec, but from what I've gathered from the list, this could, as far as the core protocol is concerned, be seen as an encryption algorithm that happens to produce ciphertext identical to the plaintext for certain parts of the data stream.
I wouldn't have a problem with that, but it's not actually the case. The base protocol spec assumes that encryption algorithms have a block size, and requires that the amount of padding be chosen such that the combined size of the length, padding length, padding, and payload be a multiple of the block size. Moving the length out of the encrypted part requires changing this behavior.
Separately, I'd like to see an unencrypted-length option so we can negotiate its use even when not using an AEAD encryption algorithm.
Does that weaken the security assurances provided by the protocol? I don't know. My feeling is that it doesn't, but there's lots of counterintuitive stuff running around crypto, and I'd need to think about it a lot more to have any degree of confidence that's right.
Agreed. We know about problems with encrypting the length as we do now, but I think we need to consider the implications of leaving it unencrypted fairly carefully.
-- Jeff