IETF Logo Mail Archive

Re: [TLS] Quest for Unified Solution to TLS Renegotiation

Eric Rescorla <ekr@networkresonance.com> Wed, 25 November 2009 23:24 UTC

Return-Path: <ekr@networkresonance.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 A3D7E3A6B74 for <tls@core3.amsl.com>; Wed, 25 Nov 2009 15:24:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.173
X-Spam-Level:
X-Spam-Status: No, score=0.173 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
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 rP3cH+nLcES3 for <tls@core3.amsl.com>; Wed, 25 Nov 2009 15:24:16 -0800 (PST)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id E57263A69C7 for <tls@ietf.org>; Wed, 25 Nov 2009 15:24:15 -0800 (PST)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 24F2A6C32B0; Wed, 25 Nov 2009 15:24:45 -0800 (PST)
Date: Wed, 25 Nov 2009 15:24:45 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Michael D'Errico <mike-list@pobox.com>
In-Reply-To: <4B0DBB97.5050500@pobox.com>
References: <4B0D9B94.9080205@pobox.com> <20091125225408.42FB96C3288@kilo.networkresonance.com> <4B0DBB97.5050500@pobox.com>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20091125232446.24F2A6C32B0@kilo.networkresonance.com>
Cc: TLS Working Group <tls@ietf.org>
Subject: Re: [TLS] Quest for Unified Solution to TLS Renegotiation
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: Wed, 25 Nov 2009 23:24:16 -0000

At Wed, 25 Nov 2009 15:19:51 -0800,
Michael D'Errico wrote:
> The complaint I have about sending the verify_data over the wire is
> that that alone does not plug the hole.  You need to take the extra
> step to check that it's correct, and a maintenance programmer not
> intimately familiar with TLS might miss this fact.

I don't find this argument very compelling. There are all sorts of
ways to screw up your TLS implementation that are worse than this
and are difficult/impossible to detect from the other side. E.g.,

- Weak randomness
- Failure to check buffers leading to buffer overflows
- Failure to check certs

TLS relies throughout on the assumption that the other side is
implemented more or less correctly. If we can't count on that,
we have bigger problems than this issue.

-Ekr

v2.23.0 | Report a Bug | By Email