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

[Viktor Dukhovni <[e-mail]>]

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.