Re: Requirements for Secondary Certificates (#522)

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).

Jeffrey