safe renegotiation: confirming consensus

[Daniel Kahn Gillmor]

On 05/03/2010 10:28 AM, Simon Josefsson wrote:
> 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:
  [...]
>   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.

NSS appears to be using this approach:

 https://wiki.mozilla.org/Security:Renegotiation#Control

That said, i don't currently see that this approach confers much of a
security advantage.

The user is already vulnerable just by having made the initial
connection (which appears to the client as a negotiation, but might
appear to the server as a renegotiation if there was a prefix injection
that already happened).

Can anyone describe what additional threat we defend against by
declining to renegotiate with vulnerable servers?

	--dkg

PS i can imagine that by declining re-negotiation we might alert the
server operator (via bug reports or error logs) that they should upgrade
their TLS toolkit, but that doesn't seem like a good tradeoff to me if
it means that we force our users to lose functionality.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 892 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20100503/0a421663/attachment.pgp>