[TLS] To API or not (Re: TLS renegotiation issue)

Nicolas Williams <Nicolas.Williams@sun.com> Fri, 06 November 2009 23:36 UTC

Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 2399F3A69D0 for <tls@core3.amsl.com>; Fri, 6 Nov 2009 15:36:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.015
X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id nMiQ8b6r6wJp for <tls@core3.amsl.com>; Fri, 6 Nov 2009 15:35:59 -0800 (PST)
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM []) by core3.amsl.com (Postfix) with ESMTP id D168E3A6898 for <tls@ietf.org>; Fri, 6 Nov 2009 15:35:58 -0800 (PST)
Received: from dm-central-02.central.sun.com ([]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA6NaES4015654 for <tls@ietf.org>; Fri, 6 Nov 2009 23:36:16 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM []) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nA6NaDAc049872 for <tls@ietf.org>; Fri, 6 Nov 2009 16:36:14 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost []) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA6N9gdl010471; Fri, 6 Nov 2009 17:09:42 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA6N9f9Z010470; Fri, 6 Nov 2009 17:09:41 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Fri, 6 Nov 2009 17:09:41 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: David Harrington <ietfdbh@comcast.net>
Message-ID: <20091106230941.GK1105@Sun.COM>
References: <20091105223130.GN1105@Sun.COM> <C719A9A7.60F0%uri@ll.mit.edu> <00bb01ca5f32$2a04ed90$1336050a@china.huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00bb01ca5f32$2a04ed90$1336050a@china.huawei.com>
User-Agent: Mutt/1.5.7i
Cc: tls@ietf.org
Subject: [TLS] To API or not (Re: TLS renegotiation issue)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Fri, 06 Nov 2009 23:36:00 -0000

On Sat, Nov 07, 2009 at 06:39:48AM +0800, David Harrington wrote:

Of course, the issue here is not "must the IETF provide APIs?" but "can
the IETF provide APIs?".  The answer to that is a resounding "yes".

> I was probably the strongest proponent of using abstract APIs
> (actually ASIs - abstract service interfaces) to depict data flows
> between parts of the system. 
> Let me observe that those ASIs have made it almost impossible to
> update the pieces of SNMPv3, because the ASIs act as design
> constraints. The strong architectural model made it very difficult to
> update the SMI without forcing changes to the ASIs. The strong
> architectural model made it very difficult to update the operations

I consider this a feature.  Not that I want to slow down development,
mind you.  Nor that I want to stay wedded to an ASI architecture that
turns out to be resistant to usefule changes.  Rather, changes to the
protocol should either be mindful of the abstract interfaces that have
been specified (i.e., the existing interfaces, possibly with extensions,
should continue to work), or they should introduce a replacement set of

> set of the SNMP protocol. Both of these efforts resulted in failed
> WGs. Adding support for existing SSH security infrastructure took
> three documents because we had  to modify the architecture, including
> all the affected ASIs. What might have taken months to complete took
> years - largely because of the use of ASIs in the architecture.

If the ASIs made it too hard to change the protocol in useful ways, then
the ASIs should be replaced.

> Many of the people who worked developed Netconf were involved in the
> SNMPv3 architecture effort, and subsequent updates. Look at the
> Netconf architecural model - it uses very simple, very nebulous
> layering as the borders between portions, not ASIs. This is a
> dramatically simpler and easier approach to work with.

I agree that it is dramatically simpler to write such documents.  I
don't agree that the result is necessarily better.  There's a whole
continuum of degree of formalism that we can use in our documents.  What
degree of formalism is best will depend on context (including who the
document authors and implementors are).  There will be contexts where
using XML schemas is useful, and ones where that would be overkill, for
example; replace XML with ASN.1/SDL/whatever.  There are contexts where
you want to use pseudo-code, or even actual source code to describe as
formally as possible, what must be done, while in other contexts "test
vectors", or just plain English language prose will do.

I think that abstract interfaces would be useful for TLS.  Most would
probably disagree.  If someday I get to be a TLS implementor, I may well
submit an individual submission I-D describing an abstract TLS API, and
maybe then I can convince the rest.  Until then I'm happy to be in the
minority, with some minor exceptions: I think it's important forthe base
TLS spec to speak of TLS connections, channel bindings for TLS
connections, and channel binding to TLS connections.

> I strongly advise you to be careful what you wish for.