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

[Daniel Kahn Gillmor <[e-mail]>]

On Tue 2015-05-12 15:29:50 -0400, Martin Rex wrote:
> With the prerequisite of a conscious and informed active consent by a human
> administrator during out-of-band maintenance/administration, using AIA to
> download a certificate can be an accetable security trade-off.
>
> But a machine/automata/algorithm that will automatically download objects
> from URLs from still-untrusted data provided by the peer is definitely
> insecure and irresponsible.

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 agree with Martin that this is super-dirty and a far more complex
system than anyone sane would have designed from first principles.  But
i still think it's the right thing to do given the ugly state of the
network today.

     --dkg