Re: [TLS] AIA cert fetching seen as harmful

[Mike <mike-list@xxxxxxxxx>]

>> What I suggested is that the information about which URL's are safe for the
>> client certificate URL extension could be embedded in the -root- certificate,
>> which you trust.
> 
> And then you look up that URL in your trusted DNS... oops.

Sure it's a potential attack, but consider the relative difficulty.  If
you do nothing and use the client certificate URL extension as it is
today, all an attacker has to do is follow the protocol and specify a
bogus URL in the client hello.  Such a program could be written in a
matter of hours and widely distributed for the amusement of script
kiddies the world over.

With the addition of URL constraints embedded in CA certificates, an
attacker would have to actively modify DNS packets or mess with routes
or whatever to launch an attack.  This is a risk that some server
operators are probably willing to take, while they would probably not
accept the problems without the constraints, except in tightly
controlled environments.

> (This also ignores the fact that you have to reissue your root cert every time
> some random server moves around, which I can't see any CA doing.  Root certs
> are issued once, given a lifetime of 20-40 years, and then never touched again
> for fear of breaking things).

You can plan for change by putting something like:

    http://*.client-cert-url-repo.some-ca.com

in the root certificate and then assigning subdomains for each
intermediate CA.  The DNS would point to the particular machine with
the certificates.  If a server moves, you just change the DNS record.
Of course with this an attacker can proxy attack the repository
machines, so that needs to be considered.

> The real problem here is that a server should never, ever initiate outgoing
> connections under the control of an external agent, which is what a lot of the
> PKIX protocols expect them to do. 

I have no stake in it, so I don't care one way or the other if the
client certificate URL extension is removed.  I just had an idea for
how to improve the situation.

Mike
_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls