[GTALUG] DNS-over-HTTPS - what's the use?

[D. Hugh Redelmeier]

| From: Nicholas Krause via talk <talk at gtalug.org>

| On 12/23/19 5:43 PM, D. Hugh Redelmeier via talk wrote:

| > It is horrible that we haven't transitioned to DNSsec.  DNS is the
| > single worst technical weakness with no excuse.  It's been 20 years of
| > almost no adoption.

| That's true. However the question is perhaps the cost of
| SSL encryption on older 20 year computers so too expensive.
| Actually most modern CPUs do encryption in instructions
| due to this. Not sure if SSL is as expensive as AES or SHA
| to compute but maybe it was.

SSL is a protocol, not a cypher.  It builds on cypher suites.  The
protocol enables negotiation of cypher suites.

The expensive part is setting up the trust:

- checking identity (e.g. with x.509 certificates)

- proving liveness (to prevent replay attacks)

- creating an ephemiral shared secret (using a Diffie Hellman
  exchange)

- mitigating Denial of Service attacks.

Computing AES and other symmetric cyphers has been quite affordable
all along, especially when you consider that DNS isn't transmitting
very much data.

We've been able to afford both of these for quite some time.

The main cost would be borne by the core.  That's where fan-in causes
a larger load (each server handles a large number of clients).  The
core can surely afford to pay for the extra hardware.  I imagine that
it's a lot less than all the neural nets in the core that recognize
speech for us.

| Also encryption or at least implementations of it in protocols
| was not taken that serious at that time. Perhaps society has
| changed too which is good, but a lot of people forget that
| the technical is dependent on other factors. Just stating
| its a weakness does not really matter but asking why I
| should care does.

I think that we are agreeing here.

This has always been important for the integrity of the internet.  The
cost is quite affordable.  Not doing this is like leaving seat belts
out of cars.

| Look at Ipv6 or hardware supported
| memory sanitizing as a example which was just being
| added to hardware even through the issue has been
| known for the last 5 years.

I don't know exactly what you mean by "memory sanitizing".

If you mean detecting the use of the value of an uninitialized
variable, effective solutions have existed for over 50 years.  Watfor
did this in the mid-1960s (originally by abusing a hardware feature
of the IBM 7040/44).

| > (I've been annoyed that so much of a resolver is embedded in glibc.)

| That makes sense from any systems programmer who
| requires nameservers or DNS. At this point not having it
| is like not having a sockets library in my view. So the
| question is why don't you think this outside of glibc
| being already bloated in size compared to other
| c libraries like musl?

The resolver is best implemented in a separate process.

The way the resolver is implemented in glibc is blocking.  This is
fine for trivial programs.  It forces more complicated programs to use
threads for no good reason.  A few little changes would allow an
asynchronous interface.

| > Conceptually, I don't like Mozilla being a single point of attack.
| > This solution really must be replaced by something better.  But will
| > it?
| Doubtful in the future probably due to security not being
| a "profit" to most companies sadly.

The other side of security is fear.  Much of our society is driven by
fear.  It isn't a small second-order effect.

| You could set it up on the
| root DNS servers and have a legacy version for non
| DHSsec connections through. Granted this would require
| a major agreement from all involved parties and basically
| require rewriting core parts of the Internet.

It's all agreed to already: DNSsec.