Re: Requirements for Secondary Certificates (#522)

On Wed, Apr 11, 2018 at 12:58 PM, Amos Jeffries <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.