[Cryptography] Doing DNS properly Re: Apple's iCloud+ "VPN"

[Phillip Hallam-Baker]

On Wed, Jun 30, 2021 at 1:28 AM Viktor Dukhovni <cryptography at dukhovni.org>
wrote:

> > On 28 Jun 2021, at 2:37 pm, Phillip Hallam-Baker <phill at hallambaker.com>
> wrote:
> >
> > Using DANE via DNS resolution is never gonna happen. It is silly to
> think it could. There is no way that google is going to delay connecting to
> a page while it waits for TLSA round trips to complete.
>
> Latency has nothing to do with it.  They wait for A/AAAA lookups to
> complete, and
> the TLSA lookup can be done in parallel with the A/AAAA lookup, and even
> overlap
> the connection establishment.  The TLSA RRs are only needed at the point
> at which
> the server certificate chain is being validated.
>

So the Google engineers I had extensive discussions with before DANE and
DPRIV began were lying and the statements they made were false.

Yes, the lookups can be done in parallel. So it is only one round trip. But
the browser still has to wait for the second lookup to complete and at the
time, the Chrome team's bonuses were tied to latency and they had no
inclination to try to persuade management to change that.

Chrome is written in C++ which doesn't support the type of await features
that would allow that type of synchronization to be done seamlessly.




> There is however a real obstacle, which is that various captive portals,
> and shitty
> ISP-provided CPEs get in the way of end-to-end DNSSEC.  This does mean
> that the
> user's stub resolver needs a way to bypass the local network, just as it
> would
> for your non-DNS protocol.
>

That is also an obstacle. But the rather larger one is that DNS registrars
don't actually make money selling DNS names, that is merely the loss leader
for their Web hosting products. And a major part of that business is
upselling customers to TLS certificates.



> Basically, the obstacle is that edge-network providers mediate DNS
> resolution.
> There are both good and bad reasons for them to do that.  The real world
> is full
> of messy trade-offs. :-(
>

The obstacle in DANE and DPRIV was that the group were persuaded to ignore
the requirements stated by the parties they needed for deployment.

I don't go to IETF to develop specifications. If I want to write a spec, I
find five or six people with some serious expertise and discuss it with
them. The only reason to take a spec to a standards org is to get buy in
from a wider constituency, to discover requirements and constraints that
had not been anticipated and fix them.

At the DPRIV kick off we were told that whatever scheme the group chose had
to be implemented within a year 'or it would fail; So the only
implementation possible was DNS over TLS. So we should use TCP Quickstart
to overcome the latency issue. So to get the protocol widely adopted we
'must' use a feature that isn't supported in Windows or macOS or iOS or
Android because designing a simple UDP key exchange tied to a DNS published
key would take too long! That was in 2014.

Now we can argue if this was merely stupidity or deliberate sabotage. But I
find it really hard to believe that both efforts to increase Internet
security were derailed in the same way and by the same individual.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210630/6dd49ddd/attachment.htm>