Re: [TLS] Next protocol negotiation

[Adam Langley <[e-mail]>]

On Thu, Jan 21, 2010 at 11:22 AM, Dean Anderson <[e-mail]> wrote:
> You do realize that using TLS as a base protocol requirement increases
> the computational and operational costs, prohibits http named virtual
> hosts, and probably other things.

I believe the point about named virtual hosting to be incorrect. I
don't know of any cases where SNI doesn't solve this.

(The level of support for SNI in the browser fleet isn't good. I have
numbers from our HTTPS servers but I've never asked to clear them for
public release. However, for new protocols this isn't an issue since
we require SNI support from our clients from the outset.)

I also don't feel that the computational overhead of encryption + MAC
is significant. You're welcome to look at
http://bench.cr.yp.to/results-stream.html for the numbers, but it ends
up being a judgement call in the end. Either way, wherever you fall on
the line, it becomes less of an issue each year.

The latency impact of TLS, of course, is significant and we're working
on more aspects of TLS than just this draft to reduce this.

> Second, I don't think protocols should be designed with too much
> emphasis on existing middleware boxes. These boxes will change as their
> users' needs change.  As was noted, the goals of these boses are not
> inherently evil, but are a tradeoff with the goals of protocol design,
> and particularly fast negotiation and other needs the protocol probably
> can't anticipate (this is layering, and is 'good'). A metaphor that
> comes to mind is the tradeoff made at the airport between fast boarding
> and security screening.  One designs aircraft and aircraft boarding
> areas with one primary goal. But terminals one must accomodate the other
> goals, (eg. security, parking, ground transportation, etc) too.

You're welcome to consider the draft on its merits irrespective of
this argument. I think it still stands.


Cheers

AGL