safe renegotiation in client side

[Daniel Kahn Gillmor]

On 03/15/2010 06:33 PM, Simon Josefsson wrote:
> Right.  But it is the server that makes the mistake of assuming that the
> newly negotiated client credentials has anything to do with the earlier
> request, isn't it?

yes, that's true, but it's true at the application layer which the TLS
implementation (and any client) can't actually know anything about.

basically, TLS without safe renegotiation has the property that any
single ongoing connection stream may in fact consist of a series of
communications with unrelated remote parties.  This property was
apparently surprising to most application developers, who were relying
on the presumed semantics that the remote endpoint in a TLS connection
would always be the same entity.

"safe renegotiation" enforces this presumed semantics.  If you're
communicating with an endpoint that does not support safe-reneg, it is
unsafe to assume those semantics hold (and so your current connection
might be part of a larger aggregated series of connections of which you
are unaware, with whatever consequences that might have on the remote peer).

> To me, the renegotiation protocol flaw means that any server that uses
> renegotiation MUST require support for safe-renegotiation in the client.
> This is a critical security issue with the server that needs to be
> addressed as quickly as possible.  I don't see any critical security
> issue on the client side at all.  The only reason clients needs to be
> upgraded is that without clients, servers will be unable to use
> renegotiation.

But clients have no way of knowing that their connections won't be seen
as part of a larger aggregate connection unless they are confident that
the server supports safe-reneg.  A client who wants to protect their
session from such a situation does need to "fail closed" when talking to
an incompatible server.

> Right, if a client has a policy of not talking to any potentially buggy
> server, this makes sense.  But I'm not sure that is useful -- servers
> are potentially buggy all the time (many still only supports SSL 3.0),
> but clients still wants to talk to them.

yup.  but if they want to talk to them with any particular security
guarantees, they need to fail to connect to peers which cannot negotiate
those security guarantees.

If you're willing to sacrifice the security guarantees (confidentiality,
authenticity, etc) for the same of just connecting, why use TLS in the
first place?

> Couldn't we be lenient today, and in 2-3 years time start to reject
> buggy servers by default?

yes, we could (though i hope that it won't be 3 years before that
happens).  I don't think that would be the worst policy to take.

But any popular TLS client implementation also plays a role in spurring
adoption of safe-reneg among servers by its choice of enforcement (and
warning messages, etc).  I'd like to see GnuTLS contribute to the "peer
pressure" here in some positive way.  i'm not saying that
default-fail-closed is necessarily the best way to do that, but an
entirely lenient policy is pretty weak on the peer pressure side and
doesn't contribute to the overall security of network communications in
general.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20100315/53b770c2/attachment.pgp>