On Wed, Apr 11, 2018 at 8:25 AM Ryan Sleevi <ryan-ietf@sleevi.com> wrote: > > > 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. > That is, effective steps to compromise *without detection*. If the attacker is willing to be detected, it'd still just take (key compromise). JeffreyReceived on Wednesday, 11 April 2018 15:29:32 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:59 UTC