[Qemu-devel] spec, RFC: TLS support for NBD

[Wouter Verhelst <w@uter.be>]

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]