[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [192.18.43.24]) 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 ([129.147.62.5]) 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 [129.153.128.104]) 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 [127.0.0.1]) 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, 06 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 interfaces. > 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. Thanks. Nico --
- [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Marsh Ray
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Marsh Ray
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Florian Weimer
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Michael D'Errico
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Florian Weimer
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- [TLS] TLS or HTTP issue? (was: TLS renegotiation … Nikos Mavrogiannopoulos
- Re: [TLS] TLS renegotiation issue Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Marsh Ray
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Cullen Jennings
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Michael Gray
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS or HTTP issue? Florian Weimer
- Re: [TLS] TLS or HTTP issue? Bruno Harbulot
- Re: [TLS] TLS renegotiation issue Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] TLS or HTTP issue? Peter Saint-Andre
- Re: [TLS] TLS or HTTP issue? Martin Rex
- Re: [TLS] TLS or HTTP issue? (was: TLS renegotiat… Nicolas Williams
- Re: [TLS] TLS or HTTP issue? (was: TLS renegotiat… Nathaniel W Filardo
- Re: [TLS] TLS or HTTP issue? Marsh Ray
- Re: [TLS] TLS or HTTP issue? (was: TLS renegotiat… Nicolas Williams
- [TLS] draft-rescorla-tls-renegotiate.txt Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Michael D'Errico
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Robert Relyea
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Michael D'Errico
- Re: [TLS] TLS or HTTP issue? Dean Anderson
- Re: [TLS] TLS renegotiation issue David Harrington
- [TLS] To API or not (Re: TLS renegotiation issue) Nicolas Williams
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Marsh Ray
- [TLS] Simple way to drop re-negotiation in HTTP (… Nicolas Williams
- Re: [TLS] TLS renegotiation issue Michael D'Errico
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Martin Rex
- Re: [TLS] Simple way to drop re-negotiation in HT… Marsh Ray
- Re: [TLS] TLS or HTTP issue? Nikos Mavrogiannopoulos
- Re: [TLS] TLS or HTTP issue? Marsh Ray
- Re: [TLS] TLS renegotiation issue Michael D'Errico
- Re: [TLS] TLS renegotiation issue Marsh Ray
- Re: [TLS] TLS or HTTP issue? Michael D'Errico
- Re: [TLS] Test Server (was TLS renegotiation issu… Michael D'Errico
- Re: [TLS] Test Server (was TLS renegotiation issu… Michael D'Errico
- Re: [TLS] TLS renegotiation issue Nagendra Modadugu
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS or HTTP issue? Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS or HTTP issue? Florian Weimer
- Re: [TLS] Simple way to drop re-negotiation in HT… Nicolas Williams
- Re: [TLS] TLS or HTTP issue? Chris Newman
- Re: [TLS] TLS or HTTP issue? (was: TLS renegotiat… Chris Newman
- Re: [TLS] TLS renegotiation issue Bodo Moeller
- Re: [TLS] TLS or HTTP issue? Nikos Mavrogiannopoulos
- [TLS] Comments on draft-rescorla-tls-renegotiate Nicolas Williams
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Martin Rex
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Nicolas Williams
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Nicolas Williams
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Nicolas Williams
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Nelson B Bolyard
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Bodo Moeller