Re: [TLS] RFC 5878 - why?

mrex@sap.com (Martin Rex) Wed, 18 September 2013 17:51 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C428B11E80EC for <tls@ietfa.amsl.com>; Wed, 18 Sep 2013 10:51:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.187
X-Spam-Level:
X-Spam-Status: No, score=-10.187 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5q27MzGErXBz for <tls@ietfa.amsl.com>; Wed, 18 Sep 2013 10:51:28 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3211D11E80A2 for <tls@ietf.org>; Wed, 18 Sep 2013 10:51:27 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8IHpIeu010995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Sep 2013 19:51:18 +0200 (MEST)
In-Reply-To: <CAGZ8ZG0840WJ9fn9uiAiGKABGC6VkaqvRopFfaE2eWd8wE4RDQ@mail.gmail.com>
To: Trevor Perrin <trevp@trevp.net>
Date: Wed, 18 Sep 2013 19:51:18 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20130918175118.A853A1A97F@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Wed, 18 Sep 2013 17:51:47 -0000
X-List-Received-Date: Wed, 18 Sep 2013 17:51:47 -0000

Trevor Perrin wrote:
>
> Yoav Nir <ynir@checkpoint.com> wrote:
> >
> > RFC 5878 is an experimental RFC. If you've looked at its history,
> > it was approved by the IESG in 2006, and an IPR issue surfaced,
> > so approval was withdrawn, and the draft lay dormant for 3 years.
> > If during those three years anyone had come up with some other
> > draft describing an authorization extension, I think that would
> > have been approved instead.
> 
> Why is there need of an "authorization extension"?

The rfc5878 seemed to have a use case, might have documented what they
had implemented, and just wanted to get this published.

Quoting from the Title page of rfc5878:

  http://tools.ietf.org/html/rfc5878

   Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

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.


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


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


> 
> TLS already has well-designed, standards-track ways of passing
> extension data back and forth:
> 
> Client -> Server : ClientHello Extension
> Client <- Server : ServerHello Extension
> Client -> Server : SupplementalData (RFC 4680)
> 
> Why is that not sufficient?

It would be sufficient.

If the stuff described in rfc5878 would have been proposed after
rfc4680 existed, it probably would have used it.  But the history
of both documents suggests that housley-tls-authz-00 is actually older
than the initial draft for rfc4680:

  https://datatracker.ietf.org/doc/rfc5878/history/
  https://datatracker.ietf.org/doc/rfc4680/history/

If you combine this kind of history with a combination of
"lack of interest" and "active disinterest because of IPR issue",
then rfc5878@Experimental is what might happen.  I naively assume that
tls-authz-extns would have died silently if Russ had not been a coauthor.


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.


-Martin