Re: [TLS] simplistic renego protection

David-Sarah Hopwood <david-sarah@jacaranda.org> Mon, 16 November 2009 20:39 UTC

Return-Path: <djhopwood@googlemail.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 97BB53A680D for <tls@core3.amsl.com>; Mon, 16 Nov 2009 12:39:33 -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=[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 PFZexvhVt+gf for <tls@core3.amsl.com>; Mon, 16 Nov 2009 12:39:32 -0800 (PST)
Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 4B47D3A689B for <tls@ietf.org>; Mon, 16 Nov 2009 12:39:32 -0800 (PST)
Received: by bwz23 with SMTP id 23so6202048bwz.29 for <tls@ietf.org>; Mon, 16 Nov 2009 12:39:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=eqGSkxGhRn680z6q6Q/Y+9TT/JxqbCTntqQ+mvHketE=; b=TAyiB5bCIGxXrPPGfNjlViVTH8l6y3GMylt1T0mESA+MOYvtGfeOjjQ3fAT+bT7/Ja LRQA60mgnWZX7CtfO1NezQJAn7L9R7yX88zG7hXKKCQPh/5+Rrh0rSMZm1dbBFlasymM 7n+fCB71ScpO7Iz34bLHhrRw73tGX5zll0nTs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=bNhDxB1ePWWhUWKY99ONtnPkajAixqbGp2W28dWN1hmORhGl2pEahXSoyywHcbQHOu i/77z4H8spHOibC2uP+cwWRx19dndnZAZiex2f48slRROLYP/WMDX8H/3+JkMJcAbl0K befsY/7pICm1YAWBhXneAQsbRQhB07eJCD4gE=
Received: by 10.204.48.131 with SMTP id r3mr5093164bkf.195.1258403967054; Mon, 16 Nov 2009 12:39:27 -0800 (PST)
Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id 31sm7323214fkt.10.2009.11.16.12.39.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 12:39:25 -0800 (PST)
Sender: David-Sarah Hopwood <djhopwood@googlemail.com>
Message-ID: <4B01B871.3050507@jacaranda.org>
Date: Mon, 16 Nov 2009 20:39:13 +0000
From: David-Sarah Hopwood <david-sarah@jacaranda.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: tls@ietf.org
References: <200911161029.nAGAT8uN019401@fs4113.wdf.sap.corp> <4B01923F.9020806@pobox.com> <4B019434.9020001@extendedsubset.com> <4B019BC7.2080201@pobox.com>
In-Reply-To: <4B019BC7.2080201@pobox.com>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------enig5C392642F3C2E14E5A2C07F2"
Subject: Re: [TLS] simplistic renego protection
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: Mon, 16 Nov 2009 20:39:33 -0000

Michael D'Errico wrote:
> If a client doesn't check the server's certificate, it is subject to
> any man-in-the-middle attack.  One of the requirements is that a client
> verify the certificate.  If a client doesn't do that, how can we
> possibly protect it???

The important case here is where client certificates are involved.
Normally, a MITM would not be able to authenticate its connection to
the server using a client cert held by the actual client -- that cert
authenticates only the connection from client to MITM, and replaying
the CertificateVerify message (in the case of a client cert with
signing ability) does not work.

Therefore, the form of the attack described by Marsh does break a
security property that TLS is intended to guarantee, independent of
any checking by the client of the server certificate.

Does anyone use "fixed_dh" client certs that lack signing ability, BTW?

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com