Re: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation

Martin Rex <> Wed, 27 January 2010 00:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6550F3A6896; Tue, 26 Jan 2010 16:05:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MSDXQ4rOtN7k; Tue, 26 Jan 2010 16:05:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3E9573A687B; Tue, 26 Jan 2010 16:05:34 -0800 (PST)
Received: from by (26) with ESMTP id o0R05eIh008305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2010 01:05:40 +0100 (MET)
From: Martin Rex <>
Message-Id: <>
To: (Peter Gutmann)
Date: Wed, 27 Jan 2010 01:05:39 +0100 (MET)
In-Reply-To: <> from "Peter Gutmann" at Jan 27, 10 12:53:39 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Subject: Re: [TLS] Metadiscussion on changes in draft-ietf-tls-renegotiation
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Jan 2010 00:05:36 -0000

Peter Gutmann wrote:
> Martin Rex <> writes:
> >That implementors should ignore at least half of the MUSTs and SHOULDs
> >in IETF documents, because they don't make any sense, create unnecessary
> >interop problems or are otherwise harmful -- and should not be in the
> >document in the first place?
> <aside>That's been the standard for PKIX RFCs for at least ten years
> (actively acknowledged by WG mmembers), although perhaps its spread
> to other groups should be discouraged.</aside>

I fully agree.

That may be attributed to the fact that a large part of PKIX is dealing
with policy issues with the objective to prevent/prohibit interoperability.

When providing software (updates) to an installed base, it is not
exactly easy to "sell" them interoperability problems, which is one
reason why the adoption speed for some PKIX features is poor.

And then there are the serious security problems created by some
of the PKIX features themselves, like AIA (Authority Identifier Access).
But basically it applies to all URLs in certs that you can use
to coerce a server in order to perform a network access of
resources according to the desire of the presenter of the certificate.