gnutls-devel
[Top][All Lists]
Advanced

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

safe renegotiation: confirming consensus


From: Simon Josefsson
Subject: safe renegotiation: confirming consensus
Date: Mon, 03 May 2010 16:28:32 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)

Based on recent discussion, here is my perception of what I believe
would be the best to implement.  Note that this is not what is
implemented today, so some of the priority strings below have slightly
different meaning now.

Client behaviour:

  Client sends the extension by default.  Can be disabled with
  %DISABLE_SAFE_RENEGOTIATION priority string.

  Clients will talk to servers that do not support the extension by
  default, but will refuse any rehandshake attempts against those
  servers.  This would cause operational problems: can we confirm that
  NSS and/or OpenSSL clients behave like this?  Otherwise we probably
  shouldn't enable it.

  When %SAFE_RENEGOTIATION is used, the client will never talk to a
  server that doesn't support the extension.

  When %UNSAFE_RENEGOTIATION is used, the client will talk to servers
  that doesn't support the extension including re-handshakes.

Server behaviour:

  Servers sends the extension by default (when the client requested it,
  of course).  Can be disabled with %DISABLE_SAFE_RENEGOTIATION priority
  string.

  Servers will accept connections from clients that do not support the
  extension, but will refuse any rehandshake attempts with that client.
  This is the important behaviour that closes the security problem for
  GnuTLS servers.  I believe we have confirmed that OpenSSL servers will
  behave like this.

  When %SAFE_RENEGOTIATION is used, the server will never talk to anyone
  who doesn't support the extension.

  When %UNSAFE_RENEGOTIATION is used, the server will talk to clients
  that doesn't support the extension including re-handshakes.

  The %INITIAL_SAFE_RENEGOTIATION is not needed anymore can be removed.

Q: should SECURE imply %SAFE_RENEGOTIATION?

Q: do we need a priority string to describe the default behaviour?  For
example %PARTIAL_RENEGOTIATION?  The reason would if you want to say
something like SECURE:%PARTIAL_RENEGOTIATION to get high-security
defaults but still support renegotiation using our normal behaviour wrt
renegotiation.

I'm not sure the terms of the priority strings are the best, the RFC
doesn't use the concept "safe renegotiation", does it?

/Simon




reply via email to

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