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 11:15:19 -0400
Message-ID: <CAErg=HE7amR_D0eOoYJWS3tUbVbpMPWVmHK5QdhR27Tn5+EC2w@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:59 UTC