Re: [TLS] simplistic renego protection

Bill Frantz <frantz@pwpconsult.com> Sat, 21 November 2009 22:04 UTC

Return-Path: <frantz@pwpconsult.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 5E76B3A6919 for <tls@core3.amsl.com>; Sat, 21 Nov 2009 14:04:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.369
X-Spam-Level:
X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74]
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 qZKrMV2dsJb2 for <tls@core3.amsl.com>; Sat, 21 Nov 2009 14:04:26 -0800 (PST)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 5D4B43A67BD for <tls@ietf.org>; Sat, 21 Nov 2009 14:04:26 -0800 (PST)
Received: from [173.75.83.34] (helo=[192.168.1.5]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <frantz@pwpconsult.com>) id 1NBy44-0002gx-9K; Sat, 21 Nov 2009 17:04:20 -0500
Date: Sat, 21 Nov 2009 14:04:33 -0800
From: Bill Frantz <frantz@pwpconsult.com>
To: Ben Laurie <benl@google.com>
X-Priority: 3
In-Reply-To: <1b587cab0911211147jf3f57b3y8528717b152cd8c2@mail.gmail.com>
Message-ID: <r02010500-1049-DA7B6A76D6E911DE826D0030658F0F64@[192.168.1.5]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.1.5 (Blindsider)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7939782feb6cbdf58fd9b7b1066d0875fd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 173.75.83.34
Cc: tls@ietf.org
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: Sat, 21 Nov 2009 22:04:27 -0000

benl@google.com (Ben Laurie) on Saturday, November 21, 2009 wrote:

>The depends on those layers. If, for example, clients and servers simply
>numbered their requests/responses, they would be immune to the attack.

and stefan@aaa-sec.com (Stefan Santesson) on Saturday, November 21, 2009 wrote:

>Or do you mean that it is impossible to design an application to be safe?

While it is possible to design an application protocol which is safe, it
isn't easy. For example, both the server and the client have to be using
the same <begin request> <end request> brackets. An attack on HTTP depends
on allowing the MITM to cause the server to process a different GET/POST
request from the one the client sent.

This bracketing issue affects even protocols like the Waterken
<http://waterken.sourceforge.net/> web-key protocol, where each request is
self-authorizing. If the MITM has a resource on the server addressable with
a web key, he can cause the client to pass parameter web-keys to that
resource rather than the resource the client thought it was addressing.

As a proof of concept that it is possible to design a safe protocol, if
each request is digitally signed by the sender, and verified by the
receiver, the MITM can not introduce superfluous data into the
conversation. If the brackets are different, the signatures don't verify.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | Airline peanut bag: "Produced  | Periwinkle
(408)356-8506      | in a facility that processes   | 16345 Englewood Ave
www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos, CA 95032