Re: [TLS] Next protocol negotiation

Adam, 

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.  Whatever you save in the first trip
is burned in the encryption/decryption later.  I think the goal of
improving connection negotiation speed is good in general, but I don't
think that using TLS is going to help other protocols connect faster.  
TLS has its own issues connecting fast (better than it was, but security
is more important---connection speed would be sacrificed for security at
the TLS layer).  And then you still have to negotiate the application
protocol, anyway.  If the application layer is progressive and slow, TLS
isn't going to change that.

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.

Third, my initial impression of the CONNECT scenario reminds me of the
old VTAM and 3270 terminals connecting to applications.  Perhaps we
should keep looking...or maybe we should reconsider VTAM or APPC... ;-)

		--Dean

On Wed, 20 Jan 2010, Adam Langley wrote:

> On Wed, Jan 20, 2010 at 7:39 AM, Nikos Mavrogiannopoulos
> <nmav@gnutls.org> wrote:
> > Ok now I see your point. However I still suggest solving issues at the
> > appropriate layer, even that has some performance cost.
> 
> The appropriate layer for protocol disambiguation is TCP.
> Unfortunately, this mechanism has stopped functioning for practical
> purposes and we're aware that we aren't the only group facing this
> problem.
> 
> Burning an additional round trip on protocol discovery is unacceptable
> for us[1]. 200ms is a good round-trip time on a 3G network and the
> nature of web content means that progressive discovery of additional
> resources amplifies this delay.
> 
> Also, consider that without a suitable mechanism, we might be
> condemning future protocols to forever limiting their initial
> handshake to something that is HTTP compatible. We (Google) don't mind
> putting in the work to make more fundamental changes but others,
> perhaps, would choose not to for reasons of expediency, and would pay
> this technical debt forever more.
> 
> [1] http://googleblog.blogspot.com/2009/06/lets-make-web-faster.html
> 
> 
> AGL
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 256 5494