W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

Re: Requirements for Secondary Certificates (#522)

From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Wed, 11 Apr 2018 13:38:00 -0400
Message-ID: <CAErg=HGkGHGUbEkeGUz2k4WZiQWTQWD8n0A2wZyHuLn2X5fDbA@mail.gmail.com>
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>
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.
Received on Wednesday, 11 April 2018 17:38:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:20 UTC