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
Eric,
(this crossed with v2)
On 7 Apr 2016, at 16:35, Eric Blake wrote:
> On 04/07/2016 06:36 AM, Alex Bligh wrote:
>>
>> On 7 Apr 2016, at 13:13, Alex Bligh wrote:
>>
>>> I guess it's worth documenting
>>> this, though I thought it was obvious.
>>
>> The next version will have this section
On 04/07/2016 06:36 AM, Alex Bligh wrote:
>
> On 7 Apr 2016, at 13:13, Alex Bligh wrote:
>
>> I guess it's worth documenting
>> this, though I thought it was obvious.
>
> The next version will have this section:
>
> ### Downgrade attacks
>
> A danger inherent in any scheme relying on th
On 7 Apr 2016, at 15:31, Eric Blake wrote:
>> +### TLS versions Certificates, authentication and authorisation
>
> s/versions/versions,/ ?
ok
>> +
>> +NBD implementations supporting TLS MUST support TLS version
>> +1.2, and MAY support other (earlier or later) versions of
>> +TLS/SSL.
>
> Al
On 04/07/2016 05:51 AM, Daniel P. Berrange wrote:
>> +
>> +There are four modes of operation for a server. The
>> +server MUST support one of these modes.
>> +
>> +* The server operates entirely without TLS ('NOTLS'); OR
>> +
>> +* The server makes TLS available (for all exports) and
>> + it is a
On 04/07/2016 05:35 AM, 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 believe
> and as a
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.
Cl
On Thu, Apr 07, 2016 at 01:13:10PM +0100, Alex Bligh wrote:
> Daniel,
>
> On 7 Apr 2016, at 12:51, Daniel P. Berrange wrote:
>
> > IMHO, we should not permit what you call OPTIONALTLS or SELECTIVETLS,
> > because these open possibilities for a MITM to perform downgrade
> > attacks, where the MIT
On 7 Apr 2016, at 13:13, Alex Bligh wrote:
> I guess it's worth documenting
> this, though I thought it was obvious.
The next version will have this section:
### Downgrade attacks
A danger inherent in any scheme relying on the negotiation
of whether TLS should be employed is downgrade attacks
Daniel,
On 7 Apr 2016, at 12:51, Daniel P. Berrange wrote:
> IMHO, we should not permit what you call OPTIONALTLS or SELECTIVETLS,
> because these open possibilities for a MITM to perform downgrade
> attacks, where the MITM runs TLS to the real server, but runs no-TLS
> to the real client.
Coul
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
* 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 believe
and as actually works in practice)
* Clarify what is a requirem
19 matches
Mail list logo
