Re: Banning TLS renegotiation

[Wouter Verhelst <w@uter.be>]

On Tue, Oct 03, 2017 at 02:59:31PM +0100, Richard W.M. Jones wrote:
> On Tue, Oct 03, 2017 at 02:48:55PM +0100, Daniel P. Berrange wrote:
> > I would say
> > 
> >   "a peer  SHOULD follow the TLS protocol spec for accepting
> >    or rejecting a renegotiation, but MAY close the connection
> >    abruptly"
> 
> How about this extension of the above:
> 
>   "A peer SHOULD follow the TLS protocol spec for accepting
>   or rejecting a renegotiation, but MAY close the connection
>   abruptly.  If the peer accepts renegotiation then it MUST
>   follow RFC5746, and it MAY limit the number of times per
>   connection that renegotiations are permitted in order to
>   prevent a possible Denial of Service attack."

I can think of one situation where TLS renegotiation would be necessary
or valid in an NBD context: if a client tries to connect to an export
which requires client certificate, but a server has several exports and
some do not. In that case, the client would do STARTTLS (the server
necessarily allowing a negotiation without certificates), and then send
NBD_OPT_GO for a certificate-requiring export. and then receive a
renegotiation request from the server so that it can provide a
certificate. The server shouldn't ask for renegotation followed by a
NBD_REP_ACK in that case (to mitigate the mitm-vulnerability in
renegotiation that was pointed to earlier), but instead some error, then
perform the renegotiation, and then the client should try the NBD_OPT_GO
again.

The error code with meaning closest to the wanted semantics would seem
to be NBD_REP_ERR_POLICY, but that could also mean other things.
Instead, I would suggest another error, NBD_REP_ERR_RENEG_REQD be added,
to tell the client that certificate authentication needs to be performed
before access to that export can be allowed.

Once the handshake phase is over though, I agree that renegotiation is
not necessary anymore, and I would therefore like to make the language
against doing so a bit stronger.

I would suggest the following instead:

  Upon receiving the NBD_OPT_GO command, a server MAY require
  renegotiation of the TLS protocol when local policy requires it (e.g.,
  because access credentials are required to allow access to a specified
  export and no such credentials were specified). If a server wishes to
  perform such renegotiation, it should reply with
  NBD_REP_ERR_RENEG_REQD and initiate the TLS renegotiation. Any state
  negotiated between client and server (e.g., block sizes) MUST be
  renegotiated after the TLS renegotiation.

  Servers SHOULD NOT request TLS renegotation in other circumstances;
  clients SHOULD NOT request it in any circumstance.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
     Hacklab