[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Nbd] [PATCH] Improve documentation for TLS

From: Wouter Verhelst
Subject: Re: [Qemu-devel] [Nbd] [PATCH] Improve documentation for TLS
Date: Sat, 9 Apr 2016 11:55:45 +0200
User-agent: Mutt/1.5.24 (2015-08-30)

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 uses FORCEDTLS, it SHOULD implement the
> > +INFO extension.
> I'd go one step further:
> If a server uses FORCEDTLS, it MUST implement the
> NBD_FLAG_FIXED_NEWSTYLE flag, and SHOULD implement the INFO extension.


> 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 works.  A server with TLS but not FIXED_NEWSTYLE is pointless

Actually, such a server is technically impossible ;-)

> (since TLS was introduced at the same time as fixed newstyle,

Eh. I don't know where you got that idea, but that's absolutely not
true. Fixed newstyle was introduced five years ago, TLS was introduced
last year or so.

> we can reasonably require, rather than just suggest, that both things
> be implemented at once to be a compliant FORCEDTLS server).

We have to make fixed newstyle a dependency of any form of tls, but
nothing more seems appropriate.

("fixed newstyle" is necessary for *anything* that is not


< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

reply via email to

[Prev in Thread] Current Thread [Next in Thread]