RE: Requirements for Secondary Certificates (#522)

Basically.  The security of the PKI infrastructure as a whole is something we should strive to improve, but we need not do that with this draft.  With this draft, my goal is simply to not make it worse.

From: Ryan Sleevi [mailto:ryan-ietf@sleevi.com]
Sent: Wednesday, April 11, 2018 10:38 AM
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: Ryan Sleevi <ryan-ietf@sleevi.com>; ietf-http-wg@w3.org Group <ietf-http-wg@w3.org>
Subject: Re: Requirements for Secondary Certificates (#522)



On Wed, Apr 11, 2018 at 12:58 PM, Amos Jeffries <squid3@treenet.co.nz<mailto:squid3@treenet.co.nz>> wrote:
ah, I see. So the aim here is just to plug the new holes added by
secondary certificates. Not to actually increase security beyond the
leaky bucket already existing?

Yes, I think the goal is to consider the change in security posture that Secondary Certificates might introduce, in terms of costs/incentives of attacks and detectability of attacks, relative to existing threats in the TLS/HTTPS ecosystem. One would also presume that a secondary goal is to ensure that improvements in other parts of the ecosystem remain applicable to use cases in which Secondary Certificates are used, or, alternatively, to ensure that other comparable mitigations exist.

In this model, DNSSEC + DANE may offer a mitigation for DNS attacks, if it was a reliable system that clients could trust, depending on your threat model. Similarly, depending on your threat model and concerns, DNS-over-HTTPS might offer an alternative mitigation. Of course, neither solution would mitigate risks of, say, BGP hijacking, whereas BGPsec might be more appropriate.

As attackers have the incentives to attack the weakest link, the goal for Secondary Certificates reasonably should be do "not be the weak link" - where weak link, in this conversation, might mean reducing the costs of attacks or reducing the chance of detection.