Re: [TLS] Next protocol negotiation

Dean Anderson <dean@av8.com> Thu, 21 January 2010 21:51 UTC

Return-Path: <dean@av8.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37763A6942 for <tls@core3.amsl.com>; Thu, 21 Jan 2010 13:51:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqY9gzoy-kXb for <tls@core3.amsl.com>; Thu, 21 Jan 2010 13:51:58 -0800 (PST)
Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 7D0FF28C0EE for <tls@ietf.org>; Thu, 21 Jan 2010 13:51:58 -0800 (PST)
Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id o0LLpR05027909 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 21 Jan 2010 16:51:28 -0500
Date: Thu, 21 Jan 2010 16:51:27 -0500 (EST)
From: Dean Anderson <dean@av8.com>
X-X-Sender: dean@citation2.av8.net
To: Adam Langley <agl@google.com>
In-Reply-To: <a84d7bc61001211140r24388501l644b47cb4868cae0@mail.gmail.com>
Message-ID: <Pine.LNX.4.44.1001211635200.531-100000@citation2.av8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Cc: tls@ietf.org
Subject: Re: [TLS] Next protocol negotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jan 2010 21:52:00 -0000

On Thu, 21 Jan 2010, Adam Langley wrote:

> On Thu, Jan 21, 2010 at 11:22 AM, Dean Anderson <dean@av8.com>; 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.

That's a good point. 

> 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.

I don't think so. As CPU's speed up improving encryption/decryption
times, so does cracking improve, resulting in deployment of more
difficult ciphers, leaving time to encrypt roughly unchanged.  So I
don't think encryption gets "easier" or less time-consuming in the
future. Again, an impression, but consider that the RSA-768 key was just
cracked, and so we recommend getting rid of 1024 bit keys. And e.g some
interesting results were published for AES-256, suggesting it will be
easier to crack than originally anticipated, meaning it will be obsolete
sooner.  

> 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.

It could be---Just my first impressions.  By all means, keep working the
problem.  Just keep an open mind that this path might be a dry hole.

Sometimes, as like DNSSEC, people become married and financially
invested in a scheme that can't work. In the worst case, they ignore the
problems and silence the critics.  But eventually, the facts always come
out.

http://lists.iadl.org/pipermail/namedroppers-honest/2010-January/000074.html


		--Dean

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