Daniel, On 7 Apr 2016, at 12:51, Daniel P. Berrange <berra...@redhat.com> wrote:
> IMHO, we should not permit what you call OPTIONALTLS or SELECTIVETLS, > because these open possibilities for a MITM to perform downgrade > attacks, where the MITM runs TLS to the real server, but runs no-TLS > to the real client. Could you describe how a downgrade attack might occur? It's always open to the client to refuse to access an export (or the server as a whole) unless TLS is negotiated, as I make clear here (see last phrase). > ## Client side requirements > > If the client supports TLS at all, it MUST be prepared > to deal with servers operating in any of the above modes. > Notwithstanding, a client MAY always disconnect or > refuse to connect to a particular export if TLS is > not available and the user requires TLS. No one should be worried about downgrade attacks on SELECTIVETLS on the exports that are not TLS only because clearly that is a risk they have decided to take by making the exports not TLS only! The only way to avoid a download attack is to make the export TLS only. SELECTIVETLS caters for the situation where the server only has some exports it wishes to secure. I guess it's worth documenting this, though I thought it was obvious. OPTIONALTLS copes with the situation where all exports fall into the above category. Here you are effectively saying the client and server agree out of band whether TLS should be compulsory, and the client will reject this if not. I think you might be making the mistake of coming at this from the perspective where there is only one export (possibly because in qemu-nbd as far as I know there is only ever one export). If you agree there is a use case for non-tls exports, and a use case for tls exports, it's difficult to argue there isn't a use case for both. On 7 Apr 2016, at 12:51, Daniel P. Berrange <berra...@redhat.com> wrote: > Both the QEMU NBD server and NBD clients only implement FORCEDTLS. > ie you tell the client to use TLS and it will refuse to talk to a > server which doesn't support TLS, and you tell the server to use > TLS and it will refuse to talk to a client which does not request > TLS So using my terminology, FORCEDTLS is something that applies only to the server, and that's fine if that's how you want your server to operate (i.e. it is permitted for it to operate only in FORCEDTLS or NOTLS mode which is what Qemu does). In qemu-NBD, it uses either FORCEDTLS or NOTLS depending on the command line - that's just fine by my proposals. Re qmeu client, if the (non-qemu) server runs in any of the TLS modes (apart from 'NOTLS') that will be compatible with the Qemu server. There will be no downgrade attack possible if the qemu client errors if it can't negotiate TLS (which it is intended to do). In qemu, the client's policy toward the server is determined by the command line as well - if TLS is specified, it insists the connection be upgraded, but if it isn't specified, it never tries to upgrade the connection. That behaviour is just fine by my proposal as well. But it doesn't mean the *server* needs to be in FORCEDTLS mode. Indeed the qemu client operates in exactly this way with my server, which is SELECTIVETLS - explicitly permitted by the INFO extension currently, and interoperability is fine. And this is perfectly compatible behaviour with what I suggest. Incidentally, the qemu client does not appear to assume the server is 'FORCEDTLS', and IIRC from time spend staring into Wireshark yesterday sends its NBD_OPT_LIST prior to the TLS upgrade. I can check that if you like. -- Alex Bligh