Re: [TLS] Renegotiation: trying to summarize

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sat, 21 June 2014 00:16 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE121A041F for <tls@ietfa.amsl.com>; Fri, 20 Jun 2014 17:16:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QZ5_zZqiS76 for <tls@ietfa.amsl.com>; Fri, 20 Jun 2014 17:16:25 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DDD81A0319 for <tls@ietf.org>; Fri, 20 Jun 2014 17:16:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1403309785; x=1434845785; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=ip37oi5q6KG0hLNFJXM0OEUM11UjZSq/RAT0WtQzdso=; b=OsC55gXfYJHVehT3vDvkl2wgBiDtDNj/eVwd4a9S2y4LySRPT4Lh/+Ff KrxtOWQtRsdrmsKCrKz4KB38znXrgsblZZs72Q+0Uqse0ZWNXJYgkTKfM kBQu1gZUf0m1swlamnAdZR+n6u1zMSrqt5eB7gNLwToL4r3H/4mt3Lf5w A=;
X-IronPort-AV: E=Sophos;i="5.01,518,1399982400"; d="scan'208";a="259752363"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Jun 2014 12:16:21 +1200
Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.9]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Sat, 21 Jun 2014 12:16:20 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Renegotiation: trying to summarize
Thread-Index: Ac+M5gaFSKrCCIhTRdiucEnoVPu4XA==
Date: Sat, 21 Jun 2014 00:16:19 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C738DECC45F@uxcn10-tdc06.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0b0S_Vp2rDJf4kQrQNdaUs01Dto
Subject: Re: [TLS] Renegotiation: trying to summarize
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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/options/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 Jun 2014 00:16:27 -0000

Martin Thomson <martin.thomson@gmail.com> writes:

>1. Remove renegotiation entirely
>
>Brian Smith proposed this.  Arguments for are its beautiful simplicity and
>the fact that it ensures that you limit the time that a single session (and
>the corresponding keys) live.

Another argument strongly in favour of removing it is that in all the
applications where I've seen a requirement for renegotiation (e.g. in industry
standards that use TLS), in approximately, oh, 100% of them it was due to some
misguided perception that it'd do... well, no-one could really explain it, but
the capability was there so we may as well add a clause requiring it.

In some cases the requirement was so clearly ridiculous (infrequent reporting
from SCADA systems where you'd need to renegotiate on each message) that
implementers chose to ignore it, but in other cases it wasn't easy to convince
people that it was pointless, particularly when some standards committee had
decided that you had to do it.

I'm strongly in favour of removing it, it's mostly pointless, it's been the
cause of the first real flaw in the SSL/TLS protocol design (rather than an
implementation issue), and it really messes things up when other standards
groups decide they need to mandate it without knowing why.

Peter.