- From: Ryan Sleevi <ryan-ietf@sleevi.com>
- Date: Wed, 11 Apr 2018 11:15:19 -0400
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Received on Wednesday, 11 April 2018 15:15:49 UTC
On Wed, Apr 11, 2018 at 1:01 AM, Amos Jeffries <squid3@treenet.co.nz> wrote: > On 11/04/18 08:20, Jeffrey Yasskin wrote: > > > > If the main problem is that Secondary Certificates make detecting > > compromise more difficult, would it help to have clients make a parallel > > connection to the DNS-discovered IP address that simply reports who's > > using the server's identity? I think it's safe for this connection to > > fail open, since if the attacker's network-privileged, they didn't need > > to use Secondary Certs. > > I don't think it would help at all. Recall that DNS/BGP is already > compromised in order to perform the attack at all. So any side > connection is just as easily caught and faked as the original was. > I think there may have been a misunderstanding. In the Secondary Certificates case, with key compromise, you can mount the attack without a DNS/BGP compromise. That is, total effort to mount attack = (key compromise). Jeffrey's suggestion is to force a connection establishment - even in the case of a Secondary Certificate offer - such that the effective steps to compromise require (key compromise) + (BGP hijack, DNS compromise, on-path presence). Which is roughly the status quo for today in a non-Secondary Certificate case.
Received on Wednesday, 11 April 2018 15:15:49 UTC