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

[Alex Bligh]

Daniel,

>> 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).
> 
> Right, so that's OK if the client is implementing FORCEDTLS.

Clients do not have named policies (at least not per
the nomenclature of the patch I sent in).

I'm taking it you mean 'if the client considers it requires
TLS'

> If the server policy is OPTIONALTLS, and the client policy
> is also OPTIONALTLS,

I'm taking it you mean 'if the client considers TLS to be optional'.

> then a MITM can just downgrade to NOTLS
> and both client & server will carry on happily in cleartext.

Yes indeed. This is an obvious result of the client
considering TLS to be optional and the server being
happy to provide plaintext.

> IOW, OPTIONALTLS is offering no meaningful security when
> both client & server policy is set that way.

It offers protection where no MTiM is possible but wiretapping
can be done.

> It is only
> safe if either the client or server run FORCEDTLS.

I believe SELECTIVETLS offers the same security on tls-only
mounts.

> This
> all makes OPTIONALTLS rather pointless, and gives people
> a false sense of security when they use it and don't
> realize it is trivially downgradable if both sides consider
> it as optional.

Well, I replied with a new section that documents this issue.
However, it's an inevitable result of a situation where TLS
is in any sense optional. That's already the case with the
INFO extension and (by my reading) without it. What I'm doing
is documenting this fact. It now (with the addition I
sent through) explicitly calls out what the risks are which
better than not calling them out (current situation).

I believe having a choice of TLS-or-not is useful provided
you know what you are doing. Note that a certain well-known
search engine seems to take the same view with its home
page.

> I don't really agree that there's a use case of mixing
> tls & non-tls exports in the same server. Sure it is
> something you can technically support, but I think it
> is really a solution in search of a problem when it comes
> to the real world,, and the most likely effect is that
> it'll just open the door to accidental security screw
> ups by people not understanding its implications.

This is *already there* in the INFO extension. I'm am
documenting it.

>> 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.
> 
> You say you're only describing these options from the server's POV, but
> I think it is clear that they need to be considered from both the client
> and server POV in order to evaluate the security characteristics.

No, I am saying the MODES I describe only apply to servers, as that's
how they are written, and they are under the section called
"Sever-side requirements"

The section "Client-side requirements" describes things from the
client's point of view. The new section I have added on "Downgrade
Attacks" (which should probably be called "Security considerations"
thinking about it) sets out how these things interoperate. Incidentally
there are two different downgrade attacks possible (on the client
and on the server).
>> 
>> 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.
> 
> If the qemu NBD client has TLS credentials set then it will
> refuse to connect to a server without TLS. The OPT_TLS is
> definitely the first thing it sends, becasue the QEMU NBD
> server will reject all options until OPT_TLS has been sent.

Yep you are right - just checked wireshark.

-- 
Alex Bligh