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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 12 May 2015 21:09 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CBF1AD17F for <tls@ietfa.amsl.com>; Tue, 12 May 2015 14:09:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uj5Y4yIda_P8 for <tls@ietfa.amsl.com>; Tue, 12 May 2015 14:09:33 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0CF11AD259 for <tls@ietf.org>; Tue, 12 May 2015 14:08:32 -0700 (PDT)
Received: by mournblade.imrryr.org (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 <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150512210831.GQ17272@mournblade.imrryr.org>
References: <20150512192950.C93F21B2EB@ld9781.wdf.sap.corp> <87lhgtbm1z.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87lhgtbm1z.fsf@alice.fifthhorseman.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Oi4FpBdLHUIri_dORh6zW95cs14>
Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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/options/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: 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
obstacle.

-- 
	Viktor.