Calling time on DNSSEC?
By Geoff Huston on 28 May 2024
- https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/

"There have been quite a few Internet technologies that have not
been enthusiastically adopted from the outset. In many cases, the
technology has been quietly discarded in favour of the next
innovation, but in some cases, the technology just refuses to go
away and sits in a protracted state of partial adoption. In some
cases, this has seen a determinate state so protracted that much of
the original rationale for the technology has been overtaken by
events and the case to support adoption needs to be rephrased in
more recent terms.
IPv6 is a good case in point where the basic architecture of the
protocol, namely as an end-to-end address-based datagram
architecture, has become an imperfect fit for a client-server
network that makes extensive use of replicated service delivery
platforms.
Today's network is undertaking a transformation to a name-based
network, and running out of addresses to the extent that it is no
longer possible to uniquely address every attached client, is no
longer the catastrophic event that we once thought it would be. We
appear to have attached some 30B devices in today's Internet, yet
in terms of IPv4 use, we have achieved this using a little over 3B
unique IPv4 addresses visible in the routing system.
In this case, I'm referring to secured DNS, or DNSSEC, which has
been tied up in progressive adoption for some 30 years. Over this
time, we've seen many theories appear as to why the pace of
adoption of DNSSEC has been so lacklustre, including a lack of
awareness, poor tooling, inability to automate operational
management, too much operational complexity and a general inability
to sustain a case that the incremental benefits of adoption of
DNSSEC far outweigh the increased operational costs and added
service fragility. Because of the lack of clear signals of general
adoption of DNSSEC over three decades, is it time to acknowledge
that DNSSEC is just not going anywhere? Is it time to call it a day
for DNSSEC and just move on?
Now admittedly this is an extreme position, and I admit to
deliberately being somewhat provocative in asking this question to
get your attention but there is a grain of an uncomfortable truth
here. As a collection of service operators, we appear not to care
sufficiently to invest in supporting the additional costs to
operate a DNSSEC-secured DNS. After some 30 years of living with a
largely insecure DNS infrastructure, we appear to be comfortable
with this outcome.
How have we got to this point?" ...

--
__ __
#_ < |\| |< _#

On 11/26/24 16:44, Computer Nerd Kev wrote:
> How have we got to this point?" ...

Too many people stop once they achieve what they think is the minimum
viable product. Basic insecure DNS is that MVP when it comes to name
resolution.

People move on to other MVP tasks that demand their attention and never
get back around to DNSSEC.

I've been using DNSSEC for 10-15 years with effectively minimal problems.

--
Grant. . . .

Grant Taylor <gtaylor@tnetconsulting.net> writes:
> On 11/26/24 16:44, Computer Nerd Kev wrote:
>> How have we got to this point?" ...
>
> Too many people stop once they achieve what they think is the minimum
> viable product. Basic insecure DNS is that MVP when it comes to name
> resolution.
>
> People move on to other MVP tasks that demand their attention and
> never get back around to DNSSEC.
>
> I've been using DNSSEC for 10-15 years with effectively minimal
> problems.

I use it too, a bit.

It’s not enough. It can secure the name-to-address mapping but does
nothing for the security of any data sent or received. You need TLS (or
SSH, or whatever) as well, and those already deal with naming. So it’s
natural to ask why someone would bother with DNSSEC as well, and hardly
surprising that mostly the answer is that people don’t.

--
https://www.greenend.org.uk/rjk/

On 27.11.2024 08:44 Uhr Computer Nerd Kev wrote:

> IPv6 is a good case in point where the basic architecture of the
> protocol, namely as an end-to-end address-based datagram
> architecture, has become an imperfect fit for a client-server
> network that makes extensive use of replicated service delivery
> platforms.

I don't see where IPv6 has any disadvantage compared to IPv4 in that
case from a technical view.

Although, IPv4 is exhausted and new companies can't be created like 20
years ago anymore. This might be a reason for some companies to stay
with it.

> Today's network is undertaking a transformation to a name-based
> network, and running out of addresses to the extent that it is no
> longer possible to uniquely address every attached client, is no
> longer the catastrophic event that we once thought it would be. We
> appear to have attached some 30B devices in today's Internet, yet
> in terms of IPv4 use, we have achieved this using a little over 3B
> unique IPv4 addresses visible in the routing system.

The NAT routers at ISPs are sometimes heavily overloaded, many
companies provide IPv6 to reduce the traffic on the NAT machines.

--
kind regards
Marco

Send spam to 1732693447muell@stinkedores.dorfdsl.de

On 11/27/24 02:40, Richard Kettlewell wrote:
> It’s not enough. It can secure the name-to-address mapping but does
> nothing for the security of any data sent or received.

DNS, without security, doesn't have anything to do with security data
sent or received either.

Apples and lug-nuts always have been and always will be completely
different things that do completely different things.

That being said, DNSSEC can be used to authenticate keys published with
DANE (TLSA records) which can be used to encrypt traffic without the
need for traditional public key infrastructure (PKI).

> You need TLS (or SSH, or whatever) as well, and those already deal
> with naming.

None of those actually do / produce the naming. They only use / consume
the naming done / produced by something else; DNS or local hosts entries.

> So it’s natural to ask why someone would bother with DNSSEC as well,
> and hardly surprising that mostly the answer is that people don’t.

See my previous response about MVP.

--
Grant. . . .

Grant Taylor <gtaylor@tnetconsulting.net> writes:
> On 11/27/24 02:40, Richard Kettlewell wrote:
>> It’s not enough. It can secure the name-to-address mapping but does
>> nothing for the security of any data sent or received.
>
> DNS, without security, doesn't have anything to do with security data
> sent or received either.
>
> Apples and lug-nuts always have been and always will be completely
> different things that do completely different things.

If you’re writing that then I don’t think you understood my point.

The problem people actually have is exchanging information with websites
without anyone else being able to read or modify that data.

DNSSEC on its own obviously can’t solve that.

DNS + TLS does solve it, sufficiently well. (Using TLS to include
Internet PKI.)

DNSSEC + TLS would also solve it, but why would someone bother with
DNSSEC when DNS+TLS is good enough for their needs?

--
https://www.greenend.org.uk/rjk/

On 11/28/24 02:52, Richard Kettlewell wrote:
> If you’re writing that then I don’t think you understood my point.

I understood your point.

I disagreed with your point.

> The problem people actually have is exchanging information with
> websites without anyone else being able to read or modify that data.

I feel the need to reiterate that the Internet is far more than just
websites or web hosted content.

> DNSSEC on its own obviously can’t solve that.

TLS on it's own can't do that either.

> DNS + TLS does solve it, sufficiently well. (Using TLS to include
> Internet PKI.)

For some nebulous value of sufficiently well.

The Internet PKI can be -> is an Achilles heal.

> DNSSEC + TLS would also solve it, but why would someone bother with
> DNSSEC when DNS+TLS is good enough for their needs?

DNS w/o DNSSEC is trusting that someone hasn't modified the data between
the authoritative source and you the consumer.

DNSSEC cryptographically authenticates the data, thus making it possible
to validate or detect modification.

Do you trust that your DNS server is giving you validated information?
Or would you like some proof that what it's giving you is validated?

There are all sorts of ways to modify DNS data in flight between clients
and authoritative servers. As previously established, TLS (et al.) by
its self isn't sufficient. TLS needs a remote endpoint to communicate
with. Name resolution is required to be able to resolve the name you
want to communicate with to an IP address to connect to. DNS is the
biggest and most common way that name resolution happens. Local hosts
files are also contenders, but they are way behind DNS.

I like to have my local DNS recursive resolver cryptographically
validate information whenever possible.

I use DNSSEC protected DNS to host things like TLS certificate public
keys with DANE and SSH fingerprints and other similar information that
allows me to function without the PKI.

It comes down to people care if the information they get from DNS is
cryptographically verifiable or not. I personally care. Many people
don't know and most of them wouldn't care.

--
Grant. . . .

Grant Taylor <gtaylor@tnetconsulting.net> writes:
> On 11/28/24 02:52, Richard Kettlewell wrote:
>> If you’re writing that then I don’t think you understood my point.
>
> I understood your point.
>
> I disagreed with your point.

You don’t seem to be engaging with it. The question is, basically, “why
does almost nobody both with DNSSEC?” The answer is, in short, because
the other tools they have available meet their needs without it. No
amount of discussion of what you can do with DNSSEC, or how it could fit
into any particular use case, or the weaknesses or otherwise of the
Internet PKI changes that.

>> The problem people actually have is exchanging information with
>> websites without anyone else being able to read or modify that data.
>
> I feel the need to reiterate that the Internet is far more than just
> websites or web hosted content.

Yes, and I covered that two or three posts ago.

--
https://www.greenend.org.uk/rjk/

On Thu, 28 Nov 2024 08:52:31 +0000, Richard Kettlewell wrote:

> DNS + TLS does solve it, sufficiently well. (Using TLS to include
> Internet PKI.)

Nobody uses PKI. TLS has a hole in it, in that the SNI, “Server Name
Indication” (the “Host:” line in the HTTP request header) has to be sent
unencrypted. This allows eavesdroppers, like authoritarian Government
regimes, to determine when you are trying to access a prohibited service,
and block it before the encrypted connection can be set up.

On 12/3/24 00:14, Lawrence D'Oliveiro wrote:
> Nobody uses PKI.

Um.... I think I'm one of many, Many, MANY people that will have to
disagree with you on hat one.

> TLS has a hole in it, in that the SNI, “Server Name Indication”
> (the “Host:” line in the HTTP request header) has to be sent
> unencrypted.

Two flags on the play:

1) Encrypted SNI is a thing.

2) "the "Host:" line in the HTTP request header" is *NOT* the SNI. The
Host: header is part of the HTTP request that's inside of the TLS
connection.

The SNI hello message does include something similar, but it's not the
Host: header. And there's also ESNI to protect it.

> This allows eavesdroppers, like authoritarian Government regimes,
> to determine when you are trying to access a prohibited service,
> and block it before the encrypted connection can be set up.

Those are examples of the very things that ESNI is designed to defend
against.

Link - What is encrypted SNI? | How ESNI works | Cloudflare
- https://www.cloudflare.com/learning/ssl/what-is-encrypted-sni/

ECH also looks promising.

--
Grant. . . .

On Tue, 3 Dec 2024 19:37:46 -0600, Grant Taylor wrote:

> 1) Encrypted SNI is a thing.

That requires a separate protocol on top of TLS.

On 12/3/24 20:02, Lawrence D'Oliveiro wrote:
> That requires a separate protocol on top of TLS.

My understanding is that ESNI is part of TLS.

--
Grant. . . .

On Tue, 3 Dec 2024 22:51:00 -0600, Grant Taylor wrote:

> On 12/3/24 20:02, Lawrence D'Oliveiro wrote:
>
>> That requires a separate protocol on top of TLS.
>
> My understanding is that ESNI is part of TLS.

It can’t be. TLS cannot start encryption on HTTP until it gets a cert that
identifies the server. That cert depends on the domain name. Which comes
from the “Host:” header line from the client. Which is why that cannot be
sent encrypted.

Grant Taylor <gtaylor@tnetconsulting.net> writes:
> On 12/3/24 00:14, Lawrence D'Oliveiro wrote:
>> Nobody uses PKI.
>
> Um.... I think I'm one of many, Many, MANY people that will have to
> disagree with you on hat one.

Quite.

>> TLS has a hole in it, in that the SNI, “Server Name Indication” (the
>> “Host:” line in the HTTP request header) has to be sent unencrypted.
>
> Two flags on the play:
>
> 1) Encrypted SNI is a thing.
>
> 2) "the "Host:" line in the HTTP request header" is *NOT* the SNI.
> The Host: header is part of the HTTP request that's inside of the TLS
> connection.

Quite.

> The SNI hello message does include something similar, but it's not the
> Host: header. And there's also ESNI to protect it.

Better than nothing, although in many cases I’d expect that traffic
analysis could be used to narrow down which site was being visited even
without name information being available.

>> This allows eavesdroppers, like authoritarian Government regimes, to
>> determine when you are trying to access a prohibited service, and
>> block it before the encrypted connection can be set up.
>
> Those are examples of the very things that ESNI is designed to defend
> against.

If there’s multiple sites served by a single IP address then the attack
can just indiscriminately block all of them. Encrypting name information
can’t prevent that.

--
https://www.greenend.org.uk/rjk/

On 12/3/24 23:49, Lawrence D'Oliveiro wrote:
> It can’t be.

Sure it can.

> TLS cannot start encryption on HTTP until it gets a cert that
> identifies the server.

The TLS connection is fully established and fully encrypted *BEFORE* any
HTTP is sent /through/ /the/ /inside/ /of/ /said/ /TLS/ connection.

> That cert depends on the domain name.

No, not quite.

The domain name can be used to inform which cert the server should use,
and that's EXACTLY what Server Name Indication (a.k.a. SNI) is. SNI is
part of TLS.

> Which comes from the “Host:” header line from the client.

Nope.

TLS can optionally send the domain name that it's going to connect to as
part of the TLS session establishment using SNI.

After the TLS session is established, then the web client sends the
Host: header.

> Which is why that cannot be sent encrypted.

Do some reading on SNI, and then ESNI. The links that I shared
previously have a decent write up.

Also, consider protocols that don't send a Host: header (as HTTP does)
still using SNI to indicate which domain name is being connected to.

You can also take a look at TLS traffic inside of Wireshark and see that
the destination name is sent very early in the connection as part of SNI.

If you have your client (Firefox) save the ephemeral keys, you can
decrypt the TLS session and see that the Host: header comes much later,
/AFTER/ the TLS connection is fully established.

--
Grant. . . .

On 12/4/24 02:39, Richard Kettlewell wrote:
> Better than nothing, although in many cases I’d expect that traffic
> analysis could be used to narrow down which site was being visited
> even without name information being available.

Yes, traffic analysis can infer and / or interfere with things.

There's also domain fronting. }:-)

> If there’s multiple sites served by a single IP address then the
> attack can just indiscriminately block all of them. Encrypting name
> information can’t prevent that.

Quite ;-)

--
Grant. . . .

On Wed, 4 Dec 2024 19:17:08 -0600, Grant Taylor wrote:

> On 12/3/24 23:49, Lawrence D'Oliveiro wrote:
>
>> That cert depends on the domain name.
>
> No, not quite.
>
> The domain name can be used to inform which cert the server should use,

Which part of “depends on” are you having trouble with?

> and that's EXACTLY what Server Name Indication (a.k.a. SNI) is. SNI is
> part of TLS.

Which cannot be sent encrypted over HTTP because HTTP encryption
hasn’t been set up yet.

> Also, consider protocols that don't send a Host: header (as HTTP does)
> still using SNI to indicate which domain name is being connected to.

They don’t do “virtual hosting”, where multiple domains share the same
IP address, and is an important feature of HTTP. That’s why there is a
specific problem with that.

There are two rival specs for solving this: DNS-over-TLS, and
DNS-over-HTTPS. DNS-over-TLS (DoT) is a separate protocol that can be
identified as such by firewalls, while DNS-over-HTTPS (DoH) is
essentially indistinguishable from any other HTTPS traffic.

DoH has become quite controversial. On the one hand, corporates who
want to control traffic on their networks for security reasons hate
it. But on the other hand, it can be useful to bypass restrictions for
those who live under certain authoritarian regimes. You can’t have
it both ways.

Mozilla decided to go for DoH, for which a British association of ISPs
called them a “villain”
<https://www.theregister.com/2019/07/10/ispa_clears_mozilla/>.

On 12/4/24 20:02, Lawrence D'Oliveiro wrote:
> Which part of “depends on” are you having trouble with?

TLS doesn't /depend/ /on/ any domain information from the client.

It's perfectly possible to use a certificate that has nothing to do with
the domain name the client was connected to.

N.B. that's entirely independent of if the client will continue using
the connection after seeing that the name in the certificate (CN and /
or SAN) doesn't match the domain name that the client thought it was
connecting to.

But the server can use whatever certificate it wants to completely
independently of the domain name that the client uses. Hence there is
no dependency.

There is correlation and usually mutual agreement. But that's not a
requirement.

> Which cannot be sent encrypted over HTTP because HTTP encryption
> hasn’t been set up yet.

Server Name Indication is part of TLS, not HTTP. HTTP comes /after/ SNI.

> They don’t do “virtual hosting”, where multiple domains share
> the same IP address, and is an important feature of HTTP. That’s
> why there is a specific problem with that.

Link - Postfix — Multiple domain SSL certificates | by Dave Teu | Better
Coder | Medium
-
https://medium.com/better-coder/postfix-multiple-domain-ssl-certificates-89c9f186ed73

Link - Dovecot SSL configuration — Dovecot documentation
-
https://doc.dovecot.org/2.3/configuration_manual/dovecot_ssl_configuration/#with-client-tls-sni-server-name-indication-support

> There are two rival specs for solving this: DNS-over-TLS, and
> DNS-over-HTTPS.

DoT & DoH are about encrypted communications with a DNS server. The are
completely independent of of TLS & SNI. What's more is that neither
DoT, nor DoH can do shit about ensuring that the data sent through the
DoT / DoH channel is valid. It's trivial to lie through DoT & DoH.
Unless client's use DNSSEC through DoT & DoH to catch the lie.

You can even use SNI while establishing a DoH session.

> DNS-over-TLS (DoT) is a separate protocol that can be identified
> as such by firewalls, while DNS-over-HTTPS (DoH) is essentially
> indistinguishable from any other HTTPS traffic.

DoH is still subject to the SNI exposure and can be filtered that way.

It's also possible to do traffic analysis to identify & block likely DoH
traffic.

> DoH has become quite controversial.

This doesn't have anything to do with TLS / SNI, so I'm not responding
to it.

--
Grant. . . .

Grant Taylor <gtaylor@tnetconsulting.net> writes:
> On 12/3/24 23:49, Lawrence D'Oliveiro wrote:
>> It can’t be.
>
> Sure it can.
>
>> TLS cannot start encryption on HTTP until it gets a cert that
>> identifies the server.
>
> The TLS connection is fully established and fully encrypted *BEFORE*
> any HTTP is sent /through/ /the/ /inside/ /of/ /said/ /TLS/
> connection.

ESNI and ECH seem to work by publishing a separate provider key. There
might be good reasons for that design in the context of TLS though it’s
not how I’d have done it, given a clean sheet.

In the abstract the purpose of a certificate in TLS-like protocols is to
provide the key used to sign the key exchange process. With (EC)DH or
ML-KEM there’s no inherent reason that has to be delivered in the
unencrypted part of the protocol; it might add another round trip to
session setup but so would gathering completely separate keys as in
ESNI/ECH, if I’ve understood them correctly.

With RSA key exchange that wouldn’t be true, but that’s out of favor for
TLS these days anyway.

--
https://www.greenend.org.uk/rjk/