RE: [hybi] workability (or otherwise) of HTTP upgrade

> -----Original Message-----
> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of
> Maciej Stachowiak
> Sent: Tuesday, December 07, 2010 2:05 AM
> To: Mark Nottingham
> Cc: hybi HTTP; HTTP Working Group
> Subject: Re: [hybi] workability (or otherwise) of HTTP upgrade
> 
> If the goal was not to interoperate with HTTP at all, it would be much
> better to use an approach where everything is encrypted. One plausible
> way to do that would be to restrict the protocol to TLS-only, at which
> point the nextprotoneg proposal can take care of dispatch without
> having to involve the HTTP layer. I think this is a plausible option,
> but many hybi WG members have expressed concern about the performance
> issues and other barriers to deployment of an all-TLS solution.
> 
> Another approach is to invent our own crypto and start with a key
> exchange. Inventing crypto makes me nervous compared to using something
> known (such TLS), and might well impose many of the same costs that
> folks are worried about with TLS.

If we are going to encrypt everything, we should just use TLS.  Crypto is an especially bad place to be reinventing the wheel.  As far as I know all the performance concerns apply to any encryption, even simple XOR masking, so there's no point in discussing tradeoffs of various implementations - the tradeoff is whether we want encryption at all.  Once we're over that hump, I don't think any custom encryption scheme is going to have benefits that outweigh TLS's huge benefit of "well understood and in wide use".

Joe

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Tuesday, 7 December 2010 15:27:54 UTC