Re: [TLS] RFC 5878 - why?

Trevor Perrin <> Wed, 18 September 2013 18:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 770CE11E8119 for <>; Wed, 18 Sep 2013 11:37:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WXrDej4iFovu for <>; Wed, 18 Sep 2013 11:37:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7C7C711E8108 for <>; Wed, 18 Sep 2013 11:37:01 -0700 (PDT)
Received: by with SMTP id w61so6992776wes.31 for <>; Wed, 18 Sep 2013 11:37:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=at1HhawljOPOKyZTtm053+oKzew6s+NuDEcenqb0hwQ=; b=TFi1tI6EFPSdXjwLffC9II7h8TpWMONt/SQmNW8tow+jl0qBdfDTnLZt0Oj7txINnn NxzkUnIFL2POjZp5YgdWIC5plotVZqwI1TrBzUM0PAClBxEmDWJuCpNT4mhclU3OAnG1 P7HO+As5DVfxhDe+14vjn0stLUFNNTeYQ5jLUWOqM/H3PmOfqjVkMZ8J7BVt1P6ocU6U z7nZij6E/DJoXVDdkiclXPYs9goblqtak+C9SAsVv7vTNiiaX9Q27g29MbjXaLkLVp96 mwN721omLoOjasrZ5n80ChiVN6QTEl4cJiq0vmnCV1iAe+NpsbpEpvXjOyTgiYRrFdab ZwKQ==
X-Gm-Message-State: ALoCoQlmAQze57yVZvuqRs0I4wNIOMYMWsRIDNnxsSuvS4iJR1P9Jb/c/v7eNzLf6wOA0qKTiL+9
MIME-Version: 1.0
X-Received: by with SMTP id xl5mr8251816wib.48.1379529420526; Wed, 18 Sep 2013 11:37:00 -0700 (PDT)
Received: by with HTTP; Wed, 18 Sep 2013 11:37:00 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <>
Date: Wed, 18 Sep 2013 11:37:00 -0700
Message-ID: <>
From: Trevor Perrin <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" <>
Subject: Re: [TLS] RFC 5878 - why?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Sep 2013 18:37:06 -0000

On Wed, Sep 18, 2013 at 10:51 AM, Martin Rex <> wrote:
> Trevor Perrin wrote:
> If a document is published by the IETF, "Experimental" is the biggest
> warning sign that we have to caution consumers, except for refusing
> to publish.

The "Experimental" marking wasn't enough to prevent people like CT,
TACK, DTCP, and OpenSSL wasting a lot of time evaluating this and
trying to use it in the last couple of years.

A bunch of code was submitted into OpenSSL for this, then had to be
ripped out, CT specs were written for it, then rewritten,  and DTCP is
still grappling with this (see Darshak's email in this thread).

If 5878 is truly redundant with RFC 5246 and 4680 then I think this
group should consider marking it "obsoleted" to steer people away from
these mistakes.

> housley-tls-authz-extns specifically had an IPR issue, which by itself
> caused active _disinterest_ in the document, I assume:

Sure, I assume that's why no-one reviewed it carefully.

> Btw. there was an announcement of an implementation of both
> rfc4680 and housley-tls-authz-extns in GnuTLS in 2007:

GnuTLS support of authz-extns was removed several months later, and
the implementor opposed publication as an RFC:

> If the stuff described in rfc5878 would have been proposed after
> rfc4680 existed, it probably would have used it.

5878 *DOES* use 4680, that's why it's so pointless.  It's a (bad)
extension mechanism nested inside of better ones.

> If you want to create an alternative to rfc5878 that makes proper use
> of rfc4680 -- go ahead.  But such an alternative might subject to the same
> IPR claims as rfc5878, so it might be the same hard sell as tls-authz-extns.

There's no need for an alternative.

TLS already has well-designed, standards-track extension mechanisms,
in the form of Hello Extensions and 4680 SupplementalData.