Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> > That's purely a client issue and has the
> > prerequisite that the client completely botches the server authentication
> > on the initial handshake
> 
> TLS specifies no requirement for the client to authenticate the server
> on the initial handshake. It is completely within the spec for a client
> to negotiate an anon-anon connection which is then upgraded to anon-cert
> or cert-cert.

That is a client-problem and the only means to fix this is to
update the client.  Personally, I consider a client plain stupid to do so.
I consider the server-anonymous ciphersuites much more dangerous
than the EXPORT ciphersuites or even the non-encrypting ciphersuites.

And most of the installed base of clients does not seem to offer
server-anonymous ciphersuites.

Keep in mind that it has been known and documented for several years that
DH_anon ciphersuites on the initial handshakes are susceptible to
man-in-the-middle attacks.

So please stop making such a big fuzz about them.

> 
> Regardless, this necessary requirement for security (that a client must
> fully validate and verify the server's certificate during and not after
> every handshake) is non-obvious and basically undocumented for
> application developers.
> 
> Heck, most of us didn't even know renegotiation existed or that our SSL
> stacks would do it automatically. There are surely applications coded by
> competent and conscientious developers which do not behave this way only
> because no one was aware of the need to do so. And that need only exists
> because TLS renegotiation was vulnerable to a MitM attack before this fix!
> 
> > and is equivalent in effectiveness to XSRF, XSS
> > and server impersonation -- something that protected TLS renegotiation
> > can not protect from.
> 
> You can't have it both ways. You can't say there's "absolutely _NO_
> known security problem" and that "protected TLS renegotiation can not
> protect from" it.

There is _NO_ known security problem in the TLS protocol.
There are only well-known and documented security problems with
the use of DH_anon ciphersuites on the initial TLS handshake.

There may be a number of flawed assumptions out there created
by clients that use the technology in an incorrect fashion.

> 
> But in fact, there is an attack.

There are possibilities to attack clients.  There is no possibility
to attack the TLS protocol.

> The good news is that having both endpoints patched to support RI,
> or just one endpoint patched and configured in strict-secure mode,
> does protect your connection from this attack.

It protects from only one particular incarnation of a number of
same-effect attacks on the same flaw in the clients architecture.


-Martin