Re: [TLS] simplistic renego protection

David-Sarah Hopwood <david-sarah@jacaranda.org> Mon, 16 November 2009 19:31 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 BBAEE28C20E for <tls@core3.amsl.com>; Mon, 16 Nov 2009 11:31:11 -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 VdLChUOOLHn7 for <tls@core3.amsl.com>; Mon, 16 Nov 2009 11:31:10 -0800 (PST)
Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 72E6228C20C for <tls@ietf.org>; Mon, 16 Nov 2009 11:31:10 -0800 (PST)
Received: by fxm7 with SMTP id 7so6131953fxm.29 for <tls@ietf.org>; Mon, 16 Nov 2009 11:31:05 -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=L/QasDaQfKxIGbTuoSucv7SY/0CxuNhb93TTxLLQ6tI=; b=bI2BrSOGbxWPS6lUL5exhYUiBxOP+YqLQmCeEmZwJkse9Tn+5sueHr/4wu0+4wbZGU UWum8iyzUiLaBf48wEDnaLkWmSZuI0Ki8V04jjA5y9x6CCeEtKUMYDL/2e9lIJIyQv9z PG2wPdHlraVX6DTkRvYjbicaYNrio/FTqThWw=
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=PpqPjCSdRB1kOTERw49vOY2Y9zVrtDKT5yPNyJiErolLSXKEhG4sAIK3dEBjppfXL2 0TxVO2cpGN9S6o/BxY0gQjj7qMuDhYL+1mrDuvRyq5xqK3djvCwqsRa8jGEBdnYPuEYz E7bKNTnitrt/JsxKMf7K4Kr+wAODxJAeIT9Aw=
Received: by 10.102.160.15 with SMTP id i15mr3838047mue.130.1258399865376; Mon, 16 Nov 2009 11:31:05 -0800 (PST)
Received: from ?192.168.0.2? (5e01843c.bb.sky.com [94.1.132.60]) by mx.google.com with ESMTPS id j6sm731869mue.20.2009.11.16.11.31.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 11:31:04 -0800 (PST)
Sender: David-Sarah Hopwood <djhopwood@googlemail.com>
Message-ID: <4B01A872.1010509@jacaranda.org>
Date: Mon, 16 Nov 2009 19:30:58 +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: <200911161405.nAGE5Vql002016@fs4113.wdf.sap.corp>
In-Reply-To: <200911161405.nAGE5Vql002016@fs4113.wdf.sap.corp>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------enig754197D11C42EE032397F51E"
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 19:31:11 -0000

Martin Rex wrote:
> Do you realize how much implementation and testing is involved when
> shipping the fix as a TLS extension.

Yes. Are you suggesting that a fix that uses some other ad hoc signalling
mechanism does not need to undergo thorough interoperability testing?

> If someone with an old server, who doesn't implement renegotiation and
> TLS extensions wants to add this patch, he will need to add the entire
> TLS extensions handling in a generic fashion and require a significantly
> larger interop testing scenario to make sure that it acutally works:

If a server doesn't implement renegotiation, then it is already as secure
as it can be with respect to this attack. The server only needs to be
patched so that strict clients will recognize it as patched.

To achieve that, the server clearly must signal something in a message
that it sends. If that is not done using an extension, then it must be
done using another mechanism such as recognizing a magic ciphersuite and
stuffing its response in some covert channel (which I cannot believe we
are even seriously discussing, frankly).

Remember, complicated kludges such as fallback to accomodate broken server
implementations are only needed, if they are needed at all, on the client
side. Implementing extensions on the server side is completely trivial.
Many server implementors have already done that work, whereas *no* server
implementors have done the work to support any newly invented signalling
mechanism.

> You're going to waste network bandwith eternally in a completely
> useless fashion.

The bandwidth usage is completely insignificant, even for highly constrained
environments. If I've calculated correctly, the size of the extension is
5 bytes in each direction in the most common, non-renegotiating case
(17 or 29 bytes when renegotiating), and it adds no round-trips. Compare
that to X.509 certificate sizes, which are typically at least 1 KiB each.

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