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

[Brian Smith <[e-mail]>]

Yoav Nir <[e-mail]> wrote:

> > 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.
>
> In that sense, how is AIA different from revocation checking? Whether you
> use CRLs or OCSP, you’re following a URL in the (still untrusted or at
> least possibly revoked) certificate to retrieve an object.
>

When you fetch CRLs or OCSP responses, you are using a URL that has been
authenticated by a trusted issuer, assuming you do revocation checking from
the root to the end-entity, which is the safer way of doing it. Whereas, in
AIA cert fetching you are making a request to an unauthenticated URL. That
is quite a big difference, because it is much harder to get a CA to sign a
certificate with your chosen OCSP URL than it is to just forge your own
certificate with whatever AIA caIssuers URL you want to have.

Ultimately, a client shouldn't fetch OCSP responses or CRLs either, for
many reasons. One of the big reasons is that those fetches greatly increase
the attack surface of the client beyond what is otherwise necessary.
Instead we need to move to a model where revocation information is always
provided within the TLS handshake (e.g. OCSP stapling and/or short-lived
certificates).

Consequently, we shouldn't accept AIA cert fetching as good or even
reasonable behavior based on analogies to revocation information fetching.

Cheers,
Brian