Re: [TLS] Heartbleed / protocol complexity
Hannes Tschofenig <hannes.tschofenig@gmx.net> Thu, 10 April 2014 23:55 UTC
Return-Path: <hannes.tschofenig@gmx.net>
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 425961A0390 for <tls@ietfa.amsl.com>; Thu, 10 Apr 2014 16:55:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.02
X-Spam-Level: **
X-Spam-Status: No, score=2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, FREEMAIL_FROM=0.001, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] 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 mL_gvxAKLrfZ for <tls@ietfa.amsl.com>; Thu, 10 Apr 2014 16:55:02 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0063F1A035B for <tls@ietf.org>; Thu, 10 Apr 2014 16:55:01 -0700 (PDT)
Received: from [192.168.37.142] ([64.134.222.118]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Me86g-1WLow03LsE-00PshE; Fri, 11 Apr 2014 01:54:59 +0200
Message-ID: <5346E261.6070602@gmx.net>
Date: Thu, 10 Apr 2014 11:26:41 -0700
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Martin Thomson <martin.thomson@gmail.com>, Hanno Böck <hanno@hboeck.de>
References: <20140409232505.0d6e02b8@hboeck.de> <CABkgnnX1hrEOmuorkx6st-0V4WAv4YQ9GjiWRtYQyeu6HTXLcA@mail.gmail.com>
In-Reply-To: <CABkgnnX1hrEOmuorkx6st-0V4WAv4YQ9GjiWRtYQyeu6HTXLcA@mail.gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="r6dIb7hs47pDq0XpiNx9QvSA9bQWHJLuw"
X-Provags-ID: V03:K0:V+C+YSixHbaTBy/H/I7zTS/bz796YbocIaF/pO2lp/1dNsvDWiP ZnA/5x4AFt1K+xUQCHAfu9Zgsl/nodY0ecmDhnZRGEA5kK0WoRHID0Uy/ZWgV/kEgxlyNDV sPrdTPo1pLcSaIHnAhws1avmso6c3NX09YQOi9Z3fVs3BtLzm9ZJqv7raVgkyO6ORLLa1ye 3J/iip9OZQ8S6P3x8PdnQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CAZqhnC_jN1G_ncKPyyH4Ahoq8I
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: Thu, 10 Apr 2014 23:55:03 -0000
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