Re: Requirements for Secondary Certificates (#522)

On 12/04/18 03:15, Ryan Sleevi wrote:
> 
> 
> On Wed, Apr 11, 2018 at 1:01 AM, Amos Jeffries <squid3@treenet.co.nz
> <mailto: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.


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?

Amos

Received on Wednesday, 11 April 2018 16:58:53 UTC