On Sat, Apr 09, 2016 at 11:04:09AM +0100, Alex Bligh wrote:
[...]
> > [...]
> >> +The server MUST NOT send `NBD_REP_ERR_TLS_REQD` in reply to
> >> +any command if TLS has already been neogitated. The server
> >
> > negotiated
>
> I'd make sure you're looking at the latest version as Eagle Eyed Er
On Sat, Apr 09, 2016 at 11:05:16AM +0100, Alex Bligh wrote:
>
> On 9 Apr 2016, at 10:50, Wouter Verhelst wrote:
>
> > So if I want to swap to qemu-nbd, I cannot also have encrypted
> > connections to the same server. Got it.
>
> AFAIK qemu-nbd only supports a single export so this isn't
> reall
On 9 Apr 2016, at 10:55, Wouter Verhelst wrote:
>
> Yes.
>
>> That way, a client can send ANY option to learn if TLS is required (even
>> an option that the server does not recognize); where NBD_OPT_INFO and
>> NBD_OPT_LIST are probably the two most useful options, but where ANY
>> option work
On 9 Apr 2016, at 10:50, Wouter Verhelst wrote:
> So if I want to swap to qemu-nbd, I cannot also have encrypted
> connections to the same server. Got it.
AFAIK qemu-nbd only supports a single export so this isn't
really an issue.
--
Alex Bligh
On 9 Apr 2016, at 10:36, Wouter Verhelst wrote:
>> +These modes of operations are described in detail below.
>> +
>> + NOTLS mode
>> +
>> +If the server receives `NBD_OPT_STARTTLS` it MUST respond with
>> +`NBD_REP_ERR_UNSUPP`. The server MUST NOT respond to any
>
> No. UNSUP (one P) is res
On Thu, Apr 07, 2016 at 08:31:23AM -0600, Eric Blake wrote:
> > +The FORCEDTLS mode of operation has an implementation problem in
> > +that the client MAY legally simply send a `NBD_OPT_EXPORT_NAME`
> > +to enter transmission mode without previously sending any options.
> > +Therefore, if a server
On Thu, Apr 07, 2016 at 02:56:48PM +0100, Daniel P. Berrange wrote:
> I don't really agree that there's a use case of mixing
> tls & non-tls exports in the same server.
There is: swap-on-NBD and TLS do not mix.
Without special handling, swapping to the network is prone to deadlocks,
because the m
On Thu, Apr 07, 2016 at 12:35:59PM +0100, Alex Bligh wrote:
> * Call out TLS into a separate section
>
> * Add details of the TLS protocol itself
>
> * Emphasise that actual TLS session initiation (i.e. the TLS handshake) can
> be initiated from either side (as required by the TLS standard I be