Re: Alternative Proposal for Two-Stage IETF Standardization
Martin Rex <mrex@sap.com> Thu, 11 November 2010 18:17 UTC
Return-Path: <mrex@sap.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B50423A67B2 for <ietf@core3.amsl.com>; Thu, 11 Nov 2010 10:17:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.145
X-Spam-Level:
X-Spam-Status: No, score=-10.145 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 A9lpRL8r8QQx for <ietf@core3.amsl.com>; Thu, 11 Nov 2010 10:17:06 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 911B23A696B for <ietf@ietf.org>; Thu, 11 Nov 2010 10:17:06 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id oABIHQxr026512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Nov 2010 19:17:26 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201011111817.oABIHPpo003318@fs4113.wdf.sap.corp>
Subject: Re: Alternative Proposal for Two-Stage IETF Standardization
To: dcrocker@bbiw.net
Date: Thu, 11 Nov 2010 19:17:25 +0100
In-Reply-To: <4CDB918C.8090902@dcrocker.net> from "Dave CROCKER" at Nov 11, 10 02:47:40 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal04
X-SAP: out
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Nov 2010 18:17:07 -0000
Dave CROCKER wrote: > > A hallway conversation with Russ added an item that simply had not > occurred to me: > > There might be multiple implementations that rely on on undocumented > modifications of the spec. This means that an additional, interoperable > implementation cannot be made purely from the specification. IMHO this is the most important aspect about "document maturity": That the document is sufficiently clear and the protocol useful _exactly_ as specified, so that whenever two independent implementations fail to interoperate that the one that must be considered broken and requires fixing is with a high probability the one that deviates from the specification, rather than require changes to the spec and all compliant implementations. There are a number of popular protocols that are heavily used, but when it comes to interoperability, the devil is in the details and the details are a huge mess. TLS is an example of plenty "defective" implementations. (e.g. protocol version numbers in various places, presence of TLS Hello extensions or (Hello) compression algorithms, (lack of) sending alerts, effect of warning level alerts on the handshake, requirement for certificate_authorities in CertificateRequest handshake message, requirement for in-order and _complete_ certificate chains, variable size padding, fragmentation of handshake messages, "server-gated crypto", sensitivity to certain certificate attributes, misappropriation of the ASN.1 type T61String, creation and distribution of commercial RootCA cert for TLS PKI that clearly violates rfc2459+rfc3280+rfc5280, to name a few) The result of the mess is that most browsers these days have given up entirely the concept of SSL/TLS interoperability and use a heuristic of reconnect fallbacks _at_the_application_level_, i.e. try a protocol feature, run into one of those interop problems, abort, and the calling app is supposed to retry with a less optimistic set of features. And there are folks who believe that every TLS-enabled application should have to implement reconnect fallback heuristics to cope with the SSL/TLS interop mess of the installed base rather than sticking with a conservative subset of TLS that _is_ fairly interoperable (extension-less TLSv1.0 or even extension-less SSLv3). -Martin
- Alternative Proposal for Two-Stage IETF Standardi… Dave CROCKER
- Re: Alternative Proposal for Two-Stage IETF Stand… Mark Andrews
- Re: Alternative Proposal for Two-Stage IETF Stand… Brian E Carpenter
- Re: Alternative Proposal for Two-Stage IETF Stand… Dave CROCKER
- Re: Alternative Proposal for Two-Stage IETF Stand… Russ Housley
- Re: Alternative Proposal for Two-Stage IETF Stand… Dave CROCKER
- Re: Alternative Proposal for Two-Stage IETF Stand… Dave CROCKER
- Re: Alternative Proposal for Two-Stage IETF Stand… Russ Housley
- Re: Alternative Proposal for Two-Stage IETF Stand… Peter Saint-Andre
- Re: Alternative Proposal for Two-Stage IETF Stand… Spencer Dawkins
- Re: Alternative Proposal for Two-Stage IETF Stand… Dave CROCKER
- Re: Alternative Proposal for Two-Stage IETF Stand… Russ Housley
- Re: Alternative Proposal for Two-Stage IETF Stand… Dave CROCKER
- Re: Alternative Proposal for Two-Stage IETF Stand… Spencer Dawkins
- Re: Alternative Proposal for Two-Stage IETF Stand… Martin Rex
- Re: Alternative Proposal for Two-Stage IETF Stand… Dave CROCKER
- Re: Alternative Proposal for Two-Stage IETF Stand… Martin Rex
- Re: Alternative Proposal for Two-Stage IETF Stand… ned+ietf
- Re: Alternative Proposal for Two-Stage IETF Stand… Spencer Dawkins
- Re: Alternative Proposal for Two-Stage IETF Stand… Eric Burger