Re: [TLS] Last Call: draft-ietf-tls-renegotiation

[Marsh Ray <[e-mail]>]

Michael D'Errico wrote:
> 
> If someone plans to make a device to detect the RI extension (possibly
> as part of a firewall or similar), then the closer it is to the front
> of the list, the less delay will be added to the processing of the
> connection, and the more connections can be handled per second.  We
> definitely don't want our fix to slow down the establishment of all
> secure connections by any significant amount.

We are talking about iterating bits of data that generally comes in over
a network, right?

Let's say the IETF gets really creative and we end up with of 20
extensions on every Client Hello. The order is well-randomized, so the
server has to "wade through" an average of 10 extensions to find the RI.
Some of these extensions are really, really big (several KB). So big
that for half of them the beginning of the next one hasn't even been
fetched into the data cache yet.

So it's reasonable to assume that the cost will be predominated by five
cold access to slow DRAM at 200ns each. Let's see that comes to... 1 us!
Well a microsecond is nothing to sneeze at.

During this microsecond many modern CPUs can be processing bits of other
connections (that do happen to be in the data cache), so some of that
might be hidden in the total throughput. Not to mention that presumably
there will be other reasons to "wade through" the extensions like if
somebody actually wants to process one for something useful. (For
comparison, my modern CPU takes about 18 ms to do an RSA in the
handshake, but I know dedicated hardware is much much faster).

Well, we don't know how long the device takes to process a handshake
without extensions, so it's hard to say what impact randomized ordering
will have.

We do know from experience that many devices end up being network-bound
rather that CPU- or memory-access-bound. It looks like there's a
two-byte length for all extensions, which strongly implies that the
maximum extension data is 64KB. Let's assume those five memory accesses
were over 16KB of data (data that somehow didn't make it into the cache).

What speed of network is necessary to be only 10 times slower than us
wading through this morass of extensions? 16KB*8/1us/10 ... I get about
13G bit/s.

So my rough estimate is that an implementation using a conventional
memory architecture could saturate a full-duplex GigE link doing nothing
but exchanging hellos loaded-out with extensions and still have 10-100x
of headroom.

This assumes of course that magic hardware makes all the other
calculations instantaneous. To the extent that assumption is false, the
overhead of wading through the extensions becomes rapidly even less
significant.

Now what happens if 90% of implementors take your recommendation and put
the RI first in the list every time (for optimum performance of course)?

A few things happen:

1. Some development group accidentally writes code that makes an
assumption that the ordering is consistent (possibly they aren't native
speakers of RFC 2119).

2. A Testing and Verification "QA" department tests their product's
interoperability with four different independent implementations. They
don't realize that all four took the recommendation on ordering, but
others that they didn't test with use some other ordering.

3. Two percent of the servers on the internet end up hanging the
connection in a slow failure mode when they get a client hello with
sub-optimally ordered extensions.

4. One of the top four major web browsers sends extensions in some
arbitrary data-dependent order. The RI extension ends up with about a
33% chance of being first. It takes a minor research effort to figure
out why 1.33% of connections end up falling back to extensionless SSLv3.

5. The hello extension mechanism gets a permanent reputation as "not
ready to require the use of on the real internet".

6. Consequently, the SNI extension is unsuitable for deployment by
shared hosting providers, so every HTTPS site needs its own IP. The
world develops an acute shortage of routable IPv4 addresses when
Twitbook buys Verisign and convinces everyone that they need a
personalized certificate for their page. Everyone switches to IPv6 (ok
now it's getting a bit far-fetched).

And last but not least:

6. Some big bloated client hello message somewhere gets processed 1
microsecond faster.

- Marsh