Re: [TLS] Heartbleed / protocol complexity
Dan Brown <dbrown@certicom.com> Fri, 11 April 2014 00:20 UTC
Return-Path: <dbrown@certicom.com>
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 B9BCC1A039B for <tls@ietfa.amsl.com>; Thu, 10 Apr 2014 17:20:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level:
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=no
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 zXVOrcyWwgQh for <tls@ietfa.amsl.com>; Thu, 10 Apr 2014 17:20:37 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3A61A0397 for <tls@ietf.org>; Thu, 10 Apr 2014 17:20:37 -0700 (PDT)
Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs210cnc.rim.net with ESMTP/TLS/AES128-SHA; 10 Apr 2014 20:20:31 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0174.001; Thu, 10 Apr 2014 20:20:30 -0400
From: Dan Brown <dbrown@certicom.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, Martin Thomson <martin.thomson@gmail.com>, Hanno Böck <hanno@hboeck.de>
Thread-Topic: [TLS] Heartbleed / protocol complexity
Thread-Index: AQHPVDo3MCEdaygBCECVzacoYA9MQpsKD9sAgAFflICAAB/Nzw==
Date: Fri, 11 Apr 2014 00:20:30 +0000
Message-ID: <20140411002030.6672532.52002.12768@certicom.com>
References: <20140409232505.0d6e02b8@hboeck.de> <CABkgnnX1hrEOmuorkx6st-0V4WAv4YQ9GjiWRtYQyeu6HTXLcA@mail.gmail.com>, <5346E261.6070602@gmx.net>
In-Reply-To: <5346E261.6070602@gmx.net>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jUmYJ9JUlj0GB09hd8W6KmRUyHI
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Heartbleed / protocol complexity
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: Fri, 11 Apr 2014 00:20:41 -0000
Could some test vectors have helped prevent this bug? Sent from my BlackBerry 10 smartphone on the Rogers network. Original Message From: Hannes Tschofenig Sent: Thursday, April 10, 2014 7:55 PM To: Martin Thomson; Hanno Böck Cc: tls@ietf.org Subject: Re: [TLS] Heartbleed / protocol complexity Hi Hanno, I agree with Martin regarding your the statement about simplicity. We always try to make extensions as simple as possible. Questions that come to my mind are: Have you provided comments at the time when RFC 6520 was written? Have you helped to improve the OpenSSL implementation of RFC 6520? There is an underlying problem that needs to be addressed, namely that we produce specifications but once we are done with the specifications we (as an organization) don't seem to care about what happens afterwards. Someone there is the impression that the developer community implements our protocols quickly and in the way we want. Assuming the existence of code that is available to the public does not necessarily mean that it is bug-free. We have many examples of this behaviour throughout the IETF (i.e., there is nothing unique to TLS). In the past I had argued that we need to take the transition from the specification (paper) to the actual implementation a bit more serious but, unfortunately, I found very little support for it. Just to give you a pointer to my most recent write-up on this topic have a look at my STRINT paper: https://www.w3.org/2014/strint/papers/62.pdf Ciao Hannes On 04/09/2014 04:28 PM, Martin Thomson wrote: > On 9 April 2014 14:25, Hanno Böck <hanno@hboeck.de> wrote: >> If it is decided that a new extension is needed it >> should be as simple as possible. > > That's a motherhood statement. Yes, RFC 6520 could have been simpler, > but it does provide a valuable function. The payload included. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- [TLS] Heartbleed / protocol complexity Hanno Böck
- Re: [TLS] Heartbleed / protocol complexity Martin Thomson
- Re: [TLS] Heartbleed / protocol complexity Nico Williams
- Re: [TLS] Heartbleed / protocol complexity Salz, Rich
- Re: [TLS] Heartbleed / protocol complexity Geoffrey Keating
- Re: [TLS] Heartbleed / protocol complexity Nico Williams
- Re: [TLS] Heartbleed / protocol complexity Nico Williams
- Re: [TLS] Heartbleed / protocol complexity Salz, Rich
- Re: [TLS] Heartbleed / protocol complexity Watson Ladd
- Re: [TLS] Heartbleed / protocol complexity Manger, James
- Re: [TLS] Heartbleed / protocol complexity Nikos Mavrogiannopoulos
- Re: [TLS] Heartbleed / protocol complexity Hannes Tschofenig
- Re: [TLS] Heartbleed / protocol complexity Dan Brown
- Re: [TLS] Heartbleed / protocol complexity Watson Ladd
- Re: [TLS] Heartbleed / protocol complexity Hanno Böck
- Re: [TLS] Heartbleed / protocol complexity Martin Rex
- Re: [TLS] Heartbleed / protocol complexity Nico Williams
- Re: [TLS] Heartbleed / protocol complexity Patrick Pelletier
- Re: [TLS] Heartbleed / protocol complexity Bill Frantz