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

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> Steve Dispensa wrote:
> > 
> > Now, of course, it's a client attack at that point, not a server attack,
> > so one might reasonably wonder whether it's the server's responsibility
> > to defend against it.
> 
> If it were a buffer overflow in the client or server code, then it would
> be a client- or server-specific attack.
> 
> In this case, it's doable with ordinary valid protocol structures and at
> least one case doesn't depend on the particulars of the implementation
> of either side. To me, that makes it a protocol attack.
> 
> Turn it around: Consider the demonstrated attack where MitM renegotiated
> with the Twitter server and caused the user of the client to publicly
> tweet his own password. Just because it was the server which saw the
> renegotiation does that make it only the concern of the server? A year
> from now, will you be willing to conduct your online banking with an
> unpatched server on the logic that it's "not my responsibility"?
> 
> Again, TLS is a general-purpose network data security protocol that's
> supposed to offer some basic guarantees. Any break in those guarantees
> is a break in the protocol. Whether or not the loss of any specific
> guarantee represents a significant problem for a specific party using
> some specific application layer protocol is irrelevent to the security
> analysis of TLS.

Your "conceived" attack has the prerequsite of the client completely
botching the server authentication.

The DH_anon ciphersuites have been known and documented to be
susceptible to man-in-the-middle attacks for several years.
This much more a defect in the design of the DH_anon ciphersuites, not
of the TLS protocol itself.  This flaw of those ciphersuites seems
to have been so non-interesting, that no-one has tried to do anything
about it.

Btw. the TLS secure renegotiation spec does _not_ affect the
susceptibility of the DH_anon ciphersuite to man-in-the-middle
attacks in any way.

Which particular (broken) clients do you have in mind that
you think need to be educated with a complete ban on interoperability?

If you want to make your servers "anal" about clients that allow
DH_anon ciphersuites, you could alternatively make your server
detect such clients and either show them special greeting pages
when they connect or abort/fail the handshake for _those_ only
(this is going to be a much smaller group).  Of the hundreds of
millions clients out there that are currently unpatched, only a
small fraction is "defective" in that it implements or
offers DH_anon ciphersuites.  


-Martin