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
>