<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <div class="moz-cite-prefix">On 4/18/2025 9:35 AM, Ron Garret wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:9FEC5CAA-2ED9-462B-94E0-435EC22EDE6C@flownet.com">
      <div><br>
        <blockquote type="cite" class="">
          <div class="">On Apr 17, 2025, at 11:10 AM, Peter Fairbrother
            <<a href="mailto:peter@tsto.co.uk"
              class="moz-txt-link-freetext">peter@tsto.co.uk</a>>
            wrote:</div>
          <br class="Apple-interchange-newline">
          <div class="">
            <div class="">On 16/04/2025 21:26, Ron Garret wrote:<br
                class="">
              <blockquote type="cite" class="">
                <blockquote type="cite" class="">On Apr 16, 2025, at
                  11:55 AM, Andrew Lee <<a
                    href="mailto:andrew@joseon.com"
                    class="moz-txt-link-freetext">andrew@joseon.com</a>>
                  wrote:<br class="">
                  <br class="">
                  Because it’s literally not any less secure than
                  getting a signed cert from a signer who signs for
                  anybody all the time (eg all of them).<br class="">
                  <br class="">
                  As an example - let’s encrypt will issue to anybody
                  who can prove control of a domain<br class="">
                </blockquote>
                You have contradicted yourself in the span of two
                sentences.  Proving control of a domain is not very
                secure, but it's not nothing either.  It does prevent
                some level of deterrence to MITM attacks, which would
                otherwise be utterly trivial.  And this deterrent, weak
                as it may be, is manifestly adequate because the web is
                not falling apart in the face of rampant MITM attacks.<br
                  class="">
              </blockquote>
              <br class="">
              Actually, if you control a domain name, you can most
              probably see/control traffic to/from it anyway. So no MITM
              needed.<br class="">
              <br class="">
              From the user POV, if the cert is issued to <a
                href="http://domain.com" class="">domain.com</a>, I'm
              talking to those who control <a href="http://domain.com"
                class="">domain.com</a>. And (hopefully!) it's DNS
              lookups. Doesn't mean they *are* <a
                href="http://domain.com" class="">domain.com</a>, just
              that they control the use of the name.<br class="">
              <br class="">
              <br class="">
              <br class="">
              If the domain in question is <a href="http://paypal.com"
                class="">paypal.com</a> or <a
                href="http://barclaysbank.com" class="">barclaysbank.com</a>,
              Paypal and Barclays should make damn sure that the real
              Paypal and Barclays bank control those names.<br class="">
              <br class="">
              Else they are (mostly) liable for fraud, in the UK at
              least - the consumer doesn't set the anti-fraud and
              security standards, the financial institution does. So it
              is responsible for failures of them.<br class="">
              <br class="">
              Hmmm I wonder why financial institutions don't weigh in on
              the matter of the subject? Liability again, I suppose. Are
              the Financial Institutions more powerful/influential than
              the "CA/Browser Forum"?<br class="">
            </div>
          </div>
        </blockquote>
      </div>
      <br class="">
      <div class="">Sorry, this makes no sense to me.  Certificates
        protect against MITM attacks, which are trivial to mount with
        wifi hotspots.  If I control the network access point someone is
        using, I control everything: DNS, routing, ICMP, the kitchen
        sink.  The *only* thing I can't do is provide attestation from a
        third party that the host serving <a href="http://paypal.com"
          class="">paypal.com</a> possesses the same key that it did the
        last time the third party tried to talk to it.  And that matters
        because the third party did not talk to <a
          href="http://paypal.com" class="">paypal.com</a> over a
        sketchy wifi hotspot, it talked to it via a hard connection to a
        router run by a known and presumably trustworthy party.</div>
      <div class=""><br class="">
      </div>
      <div class="">The point is not so much control of the domain name
        per se, as it is providing attestation of continuity of content
        between an access over a sketchy internet connection vs one that
        occurred over a (presumably) less sketchy internet connection.
         It's easy for me to MITM someone at an airport looking for free
        wifi.  It's a lot harder for me to MITM letsencrypt, and *that*
        is what matters, not the security of DNS per se.</div>
      <div class=""><br class="">
      </div>
      <div class="">rg</div>
    </blockquote>
    <p><br>
    </p>
    <p>MITM being difficult does not mean that its impossible. There are
      already examples like where attacker used BGP hijacks to issue
      themselves SSL certs [1]. It can be trivial to do if someone has
      access to ISP network where the domain name resolves to.
      Certificate Transparency is not going to help too, nobody monitors
      it.<br>
    </p>
    <p>The fix I believe is DNSSEC+DANE.<br>
    </p>
    <div class="moz-signature">
      <p>
        Regards,<br>
        <b>Shreyas Zare</b><br>
        <a href="https://technitium.com/">Technitium</a></p>
      <p>[1]
<a class="moz-txt-link-freetext" href="https://arstechnica.com/information-technology/2022/09/how-3-hours-of-inaction-from-amazon-cost-cryptocurrency-holders-235000/">https://arstechnica.com/information-technology/2022/09/how-3-hours-of-inaction-from-amazon-cost-cryptocurrency-holders-235000/</a></p>
    </div>
    <p></p>
  </body>
</html>