--On December 2, 2009 11:12:26 +0200 Yoav Nir <ynir(_at_)checkpoint(_dot_)com>
wrote:
On Dec 2, 2009, at 9:04 AM, Chris Newman wrote:
This the most time-sensitive and security-critical IETF draft with
respect to impact on the Internet community that I have seen in 17
years of IETF participation.
This is the part I disagree with.
Since that's a statement about my observations, you'd have to propose a
different draft that better met that criteria in the last 17 years and get
me to agree ;-)
New extensions to protocols will take years to deploy. There's no getting
around this.
SSL/TLS servers that do not depend on renegotiation can disable
renegotiations entirely. They can do this NOW. SSL/TLS servers that rely
on renegotiation only for the upgrade-to-mutual feature for web servers
can disable client-initiated renegotiations, and tweak their web
applications so that the prefix injection doesn't matter. The can do this
NOW. (We did)
The only real case of using renegotiation that I've heard about was
identity protection, where the client connects anonymously first, and
then presents the certificate during the (encrypted) renegotiation. This
is probably very rare, and accounts for a fraction or a percent of SSL
use.
So I don't think we should sit on our thumbs or even wait until the next
face-to-face meeting, but whatever the RFC says, it will take years to
deploy on the general Internet. We should hurry, but we shouldn't rush
into things.
The problem is more a customer-service one than a purely technical one:
there's a real problem with just turning off SSL/TLS renegotiation by
default. Yes, it's what vendors are working on doing, but it's just an
interim solution. Basically, a vendor has to go to an HTTP server customer
and say:
You need to patch your HTTP server to stop a security vulnerability
<tech babble>,
but it might break your server deployment if <tech babble>, you can work
around
that problem if you do <complex stuff> or <set flag so you stay
vulnerable>.
It doesn't matter if the downside only impacts 1% of the HTTP server
customers as the analysis of whether they'll be impacted may take time and
money and that 1% may be the people who most urgently need the
vulnerability fixed. When the vulnerability in the IETF specification is
fixed and has made it to 2-3 major browser vendors, the message to HTTP
server customers becomes more reasonable (albeit still unsatisfactory).
While the <complex stuff> is feasible for a vendor with a small HTTP
footprint and solid tech knowledge like yourself, it's less feasible for
large corporate sites that would have to analyze thousands of HTTP-based
services.
- Chris
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf