Re: [TLS] Third Option?

[Marsh Ray <[e-mail]>]

Ravi Ganesan wrote:
> 
> A third option is to leave renegotiation in, but create an advisory that
> explains the semantics;

What do you (as a vendor) tell your customers when they know they are
vulnerable and call you for a fix?

> namely, it is indeed a RE negotiation, and
> SSL/TLS itself is starting from scratch and not making any assumptions
> about what went before and what came after. A higher layer protocol that
> chooses to mix and match traffic is making assumptions about guarantees
> from the SSL/TLS layer that are certainly not "explicitly" being made
> anywhere.

Netscape's use of renegotiation of from the beginning strongly implies
they believed the guarantees were present when they added it to the
protocol.

There are still ambiguities which indicate an internal inconsistency in
the spec. For example, the spec requires that application data be
allowed to interleave with the renegotiation handshake messages. There
are multiple points during the handshake at which the identity may be
considered to have changed with various degrees of authentication.

The users on this list with the high-bandwidth links to Jupiter (who
were they again?) are quite attached to this feature.

> [...] Anyone reading about this attack from the
> media will have absolutely no clue as to impact.
> 
> Anyone who reads the  the first documents that came out on this issue
> (http://www.phonefactor.com/sslgapdocs/Renegotiating_TLS.pdf and
> http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html)
> would be left with very different perceptions of the magnitude of the
> impact. This is not unnatural in such matters; great minds usually think
> differently...., but after all this discussion perhaps a blurb in the
> draft with advice on who should immediately patch might be useful.

In short, everyone* needs to patch and disable compatible/insecure mode
as soon as is practical.

*Except those who can prove that their endpoint cannot renegotiate and
will never be willing to talk to a server that can possibly renegotiate.
Or is a protocol that perfectly discards all state on every handshake.
This is only possible with direct code inspection and protocol analysis,
and in practice experts have been repeatedly surprised by what attacks
turns out to be possible.

Someone may reply and say "Oh this particular situation doesn't need to
patch" but again, it will likely be because some systems accidentally
fall into a few narrow categories.

- Marsh