Re: Near-Real-Time TLS and DNS Validation using a Multi-Vantage-Point Network of Secure Mirrors

Dave Cridland <dave@cridland.net> Fri, 16 August 2024 13:50 UTC

Return-Path: <dave@cridland.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8556C14F693 for <ietf@ietfa.amsl.com>; Fri, 16 Aug 2024 06:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HDAItWRPs6E for <ietf@ietfa.amsl.com>; Fri, 16 Aug 2024 06:50:47 -0700 (PDT)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB6EC14F5F2 for <ietf@ietf.org>; Fri, 16 Aug 2024 06:50:47 -0700 (PDT)
Received: by mail-qt1-x82a.google.com with SMTP id d75a77b69052e-44fff73f223so11054821cf.2 for <ietf@ietf.org>; Fri, 16 Aug 2024 06:50:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; t=1723816246; x=1724421046; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Xqh831IAEsiu8NyKfNRefbGxbMe2QV4MiDdQ1swgvUk=; b=UmHpXjJDzuYhNSxK3sF6uHU+8h8pGjfQYPHxAF2PfyyLZn1wrIY6vNcsoDiX9Tr9mN 0227pj8/hT/9dY06HFjHoETRvhH1pU1lE9rDnZyt/PzcHj3mtzCeLc5C/qvwB08Ob9JP 9nsecSqwG0hUNcEd4TbPrE0HbzPI+JiSbZtCc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723816246; x=1724421046; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Xqh831IAEsiu8NyKfNRefbGxbMe2QV4MiDdQ1swgvUk=; b=UpfIuZLss6n3jyceFlSteDSv8+lmrgO8GNao60oiYPO0c1ssQ9jZkgWoZL/tOcaSh+ b0iBvsBWAZG2eOY/ldRraijj3TmAr6UINwp8Tgube9QfeIudJ0Gmo0LRlMOwia8YUDGL JdD9gdyFZlNASBVcobpve+PTkVrAM/aGNiZh7MTFA3sjryfXUNMSdn9SO5em5C1VGrEd vi8h+GL3mbPfjU+Mi/EFaLHhr4/b+G0h6nKsaR4/qcnbZelDx1T3lnTMpxH1cFH5fPoB ejXkKmhS+0dSM28+vrJpOArEwrXl5b6NzhvOAVo9Bgvr24DKrROb99jVrPFlSfqothkX X0lw==
X-Gm-Message-State: AOJu0YxaafnYTC09dL3/zMJihy1KItMLTaDEgaAtINx3byjJO2U909Y6 WLLTwcelWcsnFs6Eze1ApDdJF7WNOB+MRDUcd3jgtd094Qb14BG/eVI02/JrMwhRPHBzeEmwfqv H8fbFJ/4tq3MB790S1S1yTaf1nqjrKLO3DN/dtdLaiQX0wD4=
X-Google-Smtp-Source: AGHT+IGLCEzGNc0r3tDcSgh7E6wNylIy8xihr409t8NlVQBSqvLo4GrPtri+VmUgA2JOS+53OHo68rrF4NmgUvFRxts=
X-Received: by 2002:a05:622a:4249:b0:440:616d:9f49 with SMTP id d75a77b69052e-453742c00f0mr36479621cf.31.1723816246171; Fri, 16 Aug 2024 06:50:46 -0700 (PDT)
MIME-Version: 1.0
References: <0b313823746be8de9c9b0ba59e0f2252ae42e036.camel@ageofdream.com> <CAKr6gn3fA51Y9kb3RJx=C_en3Bi-DgRGbicfpqtZWd7RRaCxAw@mail.gmail.com> <5350.1723669821@obiwan.sandelman.ca> <070c74b38d44ad9c677c9e282646cb9caac4fc42.camel@ageofdream.com> <2a32c4e310f6c543b19d136ecd2cef3083d5de6e.camel@ageofdream.com>
In-Reply-To: <2a32c4e310f6c543b19d136ecd2cef3083d5de6e.camel@ageofdream.com>
From: Dave Cridland <dave@cridland.net>
Date: Fri, 16 Aug 2024 14:50:35 +0100
Message-ID: <CAKHUCzwP+mA31KabXqe2L9-B+c=bCWKbORUydaMhefm2prW8bw@mail.gmail.com>
Subject: Re: Near-Real-Time TLS and DNS Validation using a Multi-Vantage-Point Network of Secure Mirrors
To: Nick Lockheart <lists@ageofdream.com>
Content-Type: multipart/alternative; boundary="000000000000030050061fcd3f6f"
Message-ID-Hash: YAUUCWWXG27ZCYKAMML6TVELOPKSVGAG
X-Message-ID-Hash: YAUUCWWXG27ZCYKAMML6TVELOPKSVGAG
X-MailFrom: dave@cridland.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ietf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: ietf@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <ietf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Q-wA8f0SXx-vpgFS336rL0l4iX0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Owner: <mailto:ietf-owner@ietf.org>
List-Post: <mailto:ietf@ietf.org>
List-Subscribe: <mailto:ietf-join@ietf.org>
List-Unsubscribe: <mailto:ietf-leave@ietf.org>

I mistakenly sent a short reply only to Nick - you'd think at some point
I'd learn how to use email, but there we are.

I'll fill out my argument here - same argument, just a bit more detail.

On Thu, 15 Aug 2024 at 00:30, Nick Lockheart <lists@ageofdream.com> wrote:

>  ** INVERTING DANE **
>
> With DANE and DNSSEC, the logic goes: if the DNS record is signed by a
> trusted authority, then the browser can trust the DNS records that
> identify an unknown Certificate Authority.
>
> But this logic works the other way, too. If the browser already knows
> the fingerprint of the CA Certificate used by example.com, but the
> browser does not know the IP address, and the browser does not trust
> the DNS system, then, if the browser asks the untrusted DNS for a
> resolution of example.com, and the browser gets an IP address from the
> DNS, and the browser does a TLS handshake with the server at that IP
> address, the browser can check the fingerprint of the server's
> Certificate and know if the DNS was honest.
>
> Or in other words, cryptographically-secure DNS could verify a
> Certificate Authority, but a Certificate Authority could verify
> insecure DNS.
>
> Thus, the real problem is: how can we bootstrap trusted information
> into the browser?
>

I don't think this logic *does* work the other way.

The non-DNSSEC case with PKIX currently works because your trust anchor is
a list of CA certificates (I'll ignore "fingerprint" here because I think
that's incorrect and an implementation detail). The browser (or XMPP
server, or whatever) performs some form of endpoint discovery via the
untrusted DNS, and the net result is that the identity can be verified
irrespective of the trustworthiness of the DNS. That last is significant,
because the DNS is still not trustworthy after all this - maybe there were
some duff CNAMEs, or some bogus AAAA records inserted, but it doesn't
matter because we can prove a chain of trust back to our trust anchor
entirely independently of the DNS. This is all tantalisingly close to your
suggestion, mind, except that the DNS is still not trusted.

With DNSSEC, things are different - here, we have a trust anchor that
comprises a list of CAs *and* a DNSSEC root, so we have multiple paths we
might use, and the DNSSEC one might override, or alter, the allowable paths
through the PKIX one. DANE, then, doesn't exactly verify a Certificate
Authority, either.


>
>
>   ** A BOTTOM-UP TRUST CHAIN **
>
> We need a chain of trust, but it doesn't need to be top-down, it could
> also work bottom-up.
>
> We could build a trust model that works the other way around.
>
>
Again, I don't think you really can.

You have an entity you're trying to verify, and an entity that you trust,
and you build some kind of chain of trust between them.

When you're doing PKIX, you start with the End Entity Cert and work your
way back to a trusted CA (and from that, to the browser or operating system
vendor, typically). Typically the End Entity is kind enough to give you a
chain that gets you all (or almost all) the way back, so the job can be
quite easy - but in principle you can use various discovery methods during
path building and go grab the intermediate certificates over HTTP based on
the information encoded in the EE cert, and I'm pretty sure that OpenSSL
(for example) internally throws all the chain certificates into a bucket
and builds its own chain from them.


> Consider this example:
>
> I don't want to pick on anyone, but it's easier to explain if we use
> absolute names here, so let's use Firefox as an example.
>
> The Mozilla Foundation rolls its own CA. This CA key pair is internal
> to Mozilla, and doesn't need signed or approved by anyone.
>
> Mozilla uses the Mozilla Foundation's CA to sign all of the server
> Certificates for their own services.
>
> This Mozilla CA does not sign anything other than services owned by
> Mozilla.
>
> Mozilla places the public CA Certificate of the Mozilla Foundation into
> all of their browsers. This is the *only* CA Certificate that comes
> with the browser.
>
> Right now, the newly installed browser trusts no one. On first run,
> this happens:
>
> The browser makes a DNS request for mozilla.org and gets an IP Address
> from local DNS. This DNS response is not trusted.
>
> The browser establishes a connection to the IP address that it just
> got, and does a TLS handshake. The Certificate returned from the server
> is signed by the Mozilla Foundation's CA. Since the Mozilla
> Foundation's CA is already known to the browser, the browser now trusts
> that it is talking to the real mozilla.org server.
>
> This creates a secure channel from the browser to the browser vendor,
> which I will call BROWSER SECURE CHANNEL.
>
> This BROWSER SECURE CHANNEL allows the browser to bootstrap trust from
> the bottom up, starting by trusting itself, then by trusting its
> vendor.
>
>
So this appears to be identical in essential form to the status quo,
wherein the user trusts the browser vendor (Mozilla, here) to ship the
browser with a "good" list of CAs to trust.

The idea that Mozilla Foundation's CA is not approved to anyone isn't true
- it has to be approved (probably implicitly) by the browser's user, and as
you note has to be trusted by the browser for mozilla.org, so you are in
effect just hardcoding DANE so far.


>
>   ** BUILDING OUT TRUST **
>
> BROWSER SECURE CHANNEL lets the browser update itself from the browser
> vendor, but it also allows the browser to request something called a
> SECURE MIRROR BOOTSTRAP file.
>
> This file, requested only once when the browser is first installed,
> contains a hash/map of IP addresses and CA Fingerprints.
>
> There would be about 100 IP-CA pairs in this file.
>
> Each pair represents the identify of a SECURE MIRROR.
>
> The bootstrap file is not an exhaustive list of SECURE MIRRORS. It is
> only a small subset used for bootstrapping.
>
> Once the browser has the SECURE MIRROR BOOTSTRAP file, it will contact
> the SECURE MIRRORS on the list by their IP addresses, confirm that the
> CA fingerprint in the TLS handshake matches, then, if the server is
> validated by its CA fingerprint, the browser requests a SECURE MIRROR
> LIST from that SECURE MIRROR.
>
> The SECURE MIRROR LIST is much larger than the SECURE MIRROR BOOTSTRAP
> file, and contains IP-CA pairs for substantially more SECURE MIRRORS.
>
> The SECURE MIRRORS in this file are also grouped by region code.
>
> The browser compares the SECURE MIRROR LISTS it receives from the
> multiple SECURE MIRRORS it found in its SECURE MIRROR BOOTSTRAP file,
> and makes a master list based on consensus.
>
> This process occurs only once on browser install, and perhaps
> periodically, such as when the browser version updates.
>
>
I'd suggest "secure looking glass", because while synonyms in normal
language, "mirror" and "looking glass" have tended to have quite different
meanings as terms of art in networking.

Two problems here:

Firstly, this is still fundamentally a matter where the browser vendor
remains the trust anchor. You have not changed anything from the status
quo. In principle, each initial secure mirror might hand out a completely
different list and therefore abrogate their responsibility and break the
chain of trust back to the browser vendor.

But in practice, the browser is going to make requests to these 100 secure
mirrors and get the same list from each as it hand already, and so the list
remains stable. To assume it changes radically is to assume that the
initial secure mirrors all somehow collude to provide a different set, not
including themselves, which seems... odd?

Secondly, who runs all these secure mirrors, and why? In my
mistakenly-private note, I mentioned the word "economics", and you said
that not everything was about money. This is true; economics is not all
about money either, but it is about incentives and outcomes. What is the
incentive for an entity to be a secure mirror provider?

At first this was unclear to me, but after a bit of thought, I realised
that it's a really great way to find out what sites people are visiting.
It's at least as good as DoH (Slogan: "We'll monitor all your DNS requests
for your privacy").

I'm sure that some people will run one out of the goodness of their heart,
or because they have explicit funding to do so, like DNS root servers - but
these are going to get a lot more traffic than a DNS root server, so I'm
looking for quite big, and typically monetisable, incentives.


>
> ** VALIDATING A CA **
>
>
I'm going to shoot some fairly random holes in this, but to be clear, the
overall description appears solid to me.


> Because the above actions happen in parallel, by the time the browser
> has its A record from local DNS and has started the TLS handshake, it
> should have responses from the three SECURE MIRRORS with CA information
> from the DNS servers that each SECURE MIRROR queried.
>
>
Not true. I assume that secure mirrors operate over HTTPS, so unless you've
got an ongoing connection to the secure mirrors - and we're pickign three
at random for each request so probably not - then you have to go through
the same connection and TLS handshake, and then wait for a response. On
balance, then, I suspect this will significantly slow down initial
connections.

You can, though, complete the TLS handshake entirely (I'm ignoring early
data here) while waiting for the secure mirrors to respond, so it's not
*as* bad as you write here; the trouble is that the secure mirror has to
perform a TLS handshake with the same target at least to the point of
getting the server's certificate and its signature in order to validate the
data its about to send back, so you're adding significant overhead in
practical terms.

This, incidentally, means that traffic to the requested site will quadruple
in terms of the TLS handshakes, which will drive up the costs of hosting -
or at least load balancing in most cases. Again, economics is not all about
money, but what's the incentive here?


> If all the fingerprints match, and all the A records match, the browser
> trusts the CA and the IP.
>

You needn't compare fingerprints; you have the entire certificate. Mind
you, you'll need a list of certificates and addresses, and how they relate,
but that's all a soluble problem.


>
> ** HOW SECURE IS THIS? **
>
> Let's Encrypt is considered very secure.


OK, hold up there. ACME is considered secure enough, but I don't think
anyone assumes that ACME is as secure as it can possibly get.

As far as domain validation goes, this is arguably more secure than
> Let's Encrypt, because it is done in near-real-time, which means a
> revocation is also near real-time. Additionally, this method also
> verifies the A record for the server.
>

Oh, wait now. Revocation isn't the same as "my certificate has changed", it
can also mean "an attacker has taken complete control of my server". Your
method so far proves that everyone else sees the same certificate and
address records; it doesn't say much about compromise of either.


>
> ** HOW FAST IS THIS? **
>
> Writing out a detailed process like this makes it seem slow. But since
> the browser's request for information from SECURE MIRRORS happens at
> the same time as the normal DNS lookup, and in parallel, this should
> not add time to the page load.
>
>
Narrator: It *would* add time to the page load.


>
> ** WHO OWNS THE SECURE MIRRORS? **
>
> Everybody with an interest or stake in the Open Internet is invited and
> encouraged to operate their own SECURE MIRROR as part of a world-wide
> SECURE MIRROR NETWORK.
>
> This includes:
>
> (1) Corporations
> (2) Non-profits
> (3) Governments(*)
> (4) Universities
> (5) Individual Enthusiasts
>
>
(6) Advertising Agencies
(7) Criminals


> The requirements to operate a SECURE MIRROR are only technical, never
> political.
>

(!)


> To be a SECURE MIRROR in good standing, the SECURE MIRROR must:
>
> (1) Have a dedicated IP Address.
>
>
What does this mean? Do you mean a unique IP address only used for this
purpose? Or a unique IP address for each secure mirror that can be used for
other purposes?


> (2) Have a registered domain name.
>
>
You've stipulated that they are referenced only by IP address.


> (3) Have an Average Ping Time to the next closest SECURE MIRROR under a
> threshold.
>
>
How is this measured?


> (4) Have a Request Response Time under a threshold.
>
> (5) Have 99.9% uptime.
>
> (6) Not deny any requests (cannot be behind an application firewall
> with CAPTCHAs, for example).
>
>
Not deny *any* requests? Including DDoS?


> (7) Have a very low percentage of DISSENTS.
>
>
> (A DISSENT occurs when one SECURE MIRROR returns results that differ
> from the other two. This can occur during DNS propagation.)
>

DNS doesn't propagate; you'd write a secure mirror to query authoritative
servers directly.


>
> There should be thousands of SECURE MIRRORS, if not more.
>
> Each entity is allowed to operate only one SECURE MIRROR.
>
>
OK, how is *any* of this enforced?


> A large tech company may operate many servers behind a load balancer,
> but this is considered one SECURE MIRROR. The purpose of this rule is
> to ensure that each stakeholder gets only one "vote" in the SECURE
> MIRROR NETWORK.
>
>
How could anyone tell?

So here's a fun thought experiment - if I gradually rolled out a bunch of
these secure mirror things, and carefully responded correct data to the
others to keep mine appearing legit, could I start detecting whether the
three a browser instance was using were in fact all mine, and from that
start subverting TLS wildly? Add a DoH setup (for your privacy!) and I've
complete control over your browser. Awesome.

Obviously I needn't run thousands of instances, just add a load balancer
with a bunch of addresses on.

What prevents this? And if it's just numbers, does this mean the system
will be exceptionally vulnerable to begin with?


> A SECURE MIRROR must implement the SECURE MIRROR PROTOCOL, which is
> both a server and client protocol for a RESTful API, accessed only via
> HTTPS.
>
> Each SECURE MIRROR should have its own Certificate Authority, and use
> that Certificate Authority to sign that SECURE MIRROR'S Server
> Certificate, and nothing else.
>
>
Why does it need a distinct certificate authority? Why not just use a
self-signed cert? It makes no difference, I'm just curious.

** CONCLUSION **
>
> I am aware that I have omitted many small technical details. Some, I
> have thoughts on, and some, I would welcome the feedback of experienced
> software architects and network engineers in solving.
>

In summary, while I don't like the status quo much either, I don't think
this is workable, or indeed would replace the status quo in any useful
manner.

FWIW, I did think about doing something broadly similar, but specific to
XMPP servers, a few years back and came to the conclusion it was at best a
significant resource sink and at worst a nasty security disaster waiting to
happen.

Dave.