Re: [TLS] TLS renegotiation issue

"David Harrington" <ietfdbh@comcast.net> Fri, 06 November 2009 22:40 UTC

Return-Path: <ietfdbh@comcast.net>
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 6484C3A686C for <tls@core3.amsl.com>; Fri, 6 Nov 2009 14:40:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.224
X-Spam-Level:
X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, SARE_OBFU_ALL=0.751]
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 qEQd+h+hwnZJ for <tls@core3.amsl.com>; Fri, 6 Nov 2009 14:40:16 -0800 (PST)
Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 603693A682A for <tls@ietf.org>; Fri, 6 Nov 2009 14:40:16 -0800 (PST)
Received: from OMTA23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id 1xbW1d0011wfjNsAAyghfg; Fri, 06 Nov 2009 22:40:41 +0000
Received: from Harrington73653 ([202.106.79.2]) by OMTA23.emeryville.ca.mail.comcast.net with comcast id 1yoK1d00302zSRE8jyoP2e; Fri, 06 Nov 2009 22:49:09 +0000
From: "David Harrington" <ietfdbh@comcast.net>
To: "'Blumenthal, Uri - 0662 - MITLL'" <uri@ll.mit.edu>, "'Nicolas Williams'" <Nicolas.Williams@sun.com>, "'Marsh Ray'" <marsh@extendedsubset.com>
References: <20091105223130.GN1105@Sun.COM> <C719A9A7.60F0%uri@ll.mit.edu>
Date: Sat, 7 Nov 2009 06:39:48 +0800
Message-ID: <00bb01ca5f32$2a04ed90$1336050a@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acpeal0YLjVuNje/RNeyNT5lbOFT0AAir4d1AA7cKKA=
In-Reply-To: <C719A9A7.60F0%uri@ll.mit.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Cc: tls@ietf.org
Subject: Re: [TLS] 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 22:40:17 -0000

Hi,

I am one of the authors of RFC3411, and lead editor for the ISMS WG as
we added support for security protocols at lower layers. I was also
involved in the failed EOS WG (Evolution of SNMP) and SMING WG (next
generation SMI).

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

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 strongly advise you to be careful what you wish for. 


 

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On 
> Behalf Of Blumenthal, Uri - 0662 - MITLL
> Sent: Friday, November 06, 2009 11:24 PM
> To: Nicolas Williams; Marsh Ray
> Cc: tls@ietf.org
> Subject: Re: [TLS] TLS renegotiation issue
> 
> There's an example of using such abstract API in SNMPv3. 
> Where it was also
> debated ("IETF doesn't do API" :-), but the common sense prevailed.
> 
> 
> On 11/5/09  17:31 , "Nicolas Williams" 
> <Nicolas.Williams@sun.com> wrote:
> 
> > On Thu, Nov 05, 2009 at 04:28:57PM -0600, Marsh Ray wrote:
> >> Nicolas Williams wrote:
> >>> I don't think it was ever really true that "the IETF 
> doesn't do APIs".
> >> 
> >> I would add here that if the IETF had compared the way TLS 
> looks on the
> >> wire with how it is presented by SSL APIs in practice, 
> this defect could
> >> not have gone unnoticed.
> > 
> > Indeed.  Larry Zhu described to me how the SSPI models TLS 
> just a few
> > days ago.  I should have noticed immediately the lack of 
> binding, but
> > because I wasn't also thinking of HTTPS, I didn't.
> > 
> > I'd go far enough to say that we must consider at least 
> abstract APIs to
> > protocols such as TLS.
> > 
> > Nico
> 
> -- 
> Regards,
> Uri         uri@ll.mit.edu
> <Disclaimer>
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>