Re: [TLS] Next protocol negotiation

Dean Anderson <> Thu, 21 January 2010 21:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F37763A6942 for <>; Thu, 21 Jan 2010 13:51:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yqY9gzoy-kXb for <>; Thu, 21 Jan 2010 13:51:58 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7D0FF28C0EE for <>; Thu, 21 Jan 2010 13:51:58 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (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
From: Dean Anderson <>
To: Adam Langley <>
In-Reply-To: <>
Message-ID: <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Subject: Re: [TLS] Next protocol negotiation
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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
> 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

> 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


Av8 Internet   Prepared to pay a premium for better service?         faster, more reliable, better service
617 256 5494