Re: [TLS] RFC 5878 - why?

[Trevor Perrin <[e-mail]>]

On Wed, Sep 18, 2013 at 10:51 AM, Martin Rex <[e-mail]> 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:
>
>   http://www.ietf.org/mail-archive/web/tls/current/msg01523.html

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:
>   http://www.ietf.org/mail-archive/web/tls/current/msg01518.html

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

http://www.ietf.org/mail-archive/web/ietf/current/msg48545.html


> 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.


Trevor