[Top][All Lists]
[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
- safe renegotiation: confirming consensus,
Simon Josefsson <=