Re: [libvirt] spec, RFC: TLS support for NBD

Hi all, (added rjones from nbdkit fame -- hi there)

So I think the following would make sense to allow TLS in NBD. This would extend the newstyle negotiation by adding two options (i.e., client requests), one server reply, and one server error as well as extend one existing reply, in the following manner: - The two new commands are NBD_OPT_PEEK_EXPORT and NBD_OPT_STARTTLS. The former would be used to verify if the server will do TLS for a given export: C: NBD_OPT_PEEK_EXPORT S: NBD_REP_SERVER, with an extra field after the export name containing flags that describe the export (R/O vs R/W state, whether TLS is allowed and/or required). If the server indicates that TLS is allowed, the client may now issue NBD_OPT_STARTTLS: C: NBD_OPT_STARTTLS S: NBD_REP_STARTTLS # or NBD_REP_ERR_POLICY, if unwilling C: <initiate TLS handshake> Once the TLS handshake has completed, negotiation should continue over the secure channel. The client should initiate that by sending an NBD_OPT_* message. - The server may reply to any and all negotiation request with NBD_REP_ERR_TLS_REQD if it does not want to do anything without TLS. However, if at least one export is supported without encryption, the server must not in any case use this reply. There is no command to "exit" TLS again. I don't think that makes sense, but I could be persuaded otherwise with sound technical arguments. Thoughts? (full spec (with numbers etc) exists as an (uncommitted) diff to doc/proto.txt on my laptop, ...) -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26