Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)

Viktor Dukhovni <> Tue, 12 May 2015 21:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 24CBF1AD17F for <>; Tue, 12 May 2015 14:09:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Uj5Y4yIda_P8 for <>; Tue, 12 May 2015 14:09:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E0CF11AD259 for <>; Tue, 12 May 2015 14:08:32 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 535AE283031; Tue, 12 May 2015 21:08:31 +0000 (UTC)
Date: Tue, 12 May 2015 21:08:31 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)
X-Mailman-Version: 2.1.15
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: Tue, 12 May 2015 21:09:35 -0000

On Tue, May 12, 2015 at 04:03:36PM -0400, Daniel Kahn Gillmor wrote:

> Doesn't this argument suggest that we should go ahead and relax the text
> as suggested?
> If:
>  * automated cert fetching is bad (i'm inclined to agree with you about
>    this, Martin, since it would embed www-like promiscuous network
>    activity in protocols that don't currently suffer from it), and
>  * cert validation is hard (as evidenced by the litany of problems
>    people have getting it right), and
>  * no unified/global trust anchor exists (because people have different
>    perspectives on the world), and
>  * servers don't know what the clients preferred trust anchors are (and
>    probably shouldn't require the client to announce this perspective to
>    perform a TLS handshake, for privacy reasons), and
>  * we need to be able to upgrade existing PKI smoothly, because breaking
>    existing clients will prevent most deployers from ever upgrading
>    anything,
> Then:
>  * it seems like we ought to explicitly permit servers to ship the
>    certificates capable of forming multiple verification chains in the
>    TLS handshake, so that clients have all the certs they need to find
>    their preferred path, without having to do AIA fetching.
> Given that servers *already do this*, the argument seems even stronger.

I don't know which clients choke on bags/heaps of certificates
rather than linear chains.  OpenSSL tolerates a heap.  However, as
mentioned previously for OpenSSL clients, the heap contains an
equivalent chain that works equally well for those clients.

Thus one can take a middle ground, where servers are allowed to
send non-chains (heaps/bags/...), but clients are *not* required
or expected to try all possible paths.  To the extent that some
clients try multiple paths, the server operator may benefit from
such a configuration, but various clients will build some single
path out of the heap and either succeed or fail with that.

Allowing servers to send a heap seems mostly harmless, provided
we're not also *requiring* clients to do the full combinatorial
explosion path construction.  If the extent of the change is
to allow mutually consenting clients and servers to play that
game, I have no objections.  

That does of course introduce possible harm to clients that simply
don't work when given a heap even to the extent of building a single
candidate chain.  No idea whether such clients are a significant