IETF Logo Mail Archive

Re: [TLS] SSL Renegotiation DOS

"Steve Dispensa" <dispensa@phonefactor.com> Tue, 15 March 2011 19:50 UTC

Return-Path: <dispensa@phonefactor.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 CA3CE3A6E68 for <tls@core3.amsl.com>; Tue, 15 Mar 2011 12:50:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Qa-ZO5ugaoVZ for <tls@core3.amsl.com>; Tue, 15 Mar 2011 12:50:50 -0700 (PDT)
Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by core3.amsl.com (Postfix) with SMTP id BE8DA3A6A8B for <tls@ietf.org>; Tue, 15 Mar 2011 12:50:49 -0700 (PDT)
Received: from source ([204.13.120.8]) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTX/Db6VWBeS/DEds7/RjZx/fg3hEKYDV@postini.com; Tue, 15 Mar 2011 12:52:15 PDT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 15 Mar 2011 14:52:14 -0500
Message-ID: <0F7F9A82BB0DBB4396A9F8386D0E06120662315D@pos-exch1.corp.positivenetworks.net>
In-Reply-To: <4D7F95AA.8060007@extendedsubset.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] SSL Renegotiation DOS
Thread-Index: AcvjL0E1VJB3havYRNGrsB5skwLiYwAGhMrg
References: <AANLkTin2i3+K8oV68pZFJ0xabjEugJLePyZTTaZSr0VE@mail.gmail.com> <201103151607.p2FG7g47008253@fs4113.wdf.sap.corp><AANLkTikXumkgN8AGs_kPQJy2Bs7sG2HuGnrHTA4HCwxu@mail.gmail.com> <4D7F95AA.8060007@extendedsubset.com>
From: Steve Dispensa <dispensa@phonefactor.com>
To: Marsh Ray <marsh@extendedsubset.com>, Eric Rescorla <ekr@rtfm.com>
Cc: tls@ietf.org
Subject: Re: [TLS] SSL Renegotiation DOS
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: Tue, 15 Mar 2011 19:50:50 -0000

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
> Marsh Ray
>
> Presumably, somewhere there is a TCP-based load-balancing DoS
prevention
> system protecting a TLS server that allows client-initiated
> renegotiation. This system may do a good job of resisting DoSes on the
> initial handshake but not DoSes on renegotiation handshakes.

Yes; any DoS mitigation work that has been done on initial handshakes
should also be done on renegotiations. It wouldn't surprise me if there
are implementations out there for which this is not the case. (Not that
I have any evidence, but I'm eagerly awaiting the results of Jorge's
search.)

If nothing else, it'd be good advice for implementers to keep in mind
going forward.

 -Steve

v2.27.6 | Report a Bug | By Email | System Status