Path: ...!weretis.net!feeder9.news.weretis.net!tncsrv06.tnetconsulting.net!tncsrv09.home.tnetconsulting.net!.POSTED.198.18.1.11!not-for-mail
From: Grant Taylor <gtaylor@tnetconsulting.net>
Newsgroups: comp.misc
Subject: Re: [LINK] Calling time on DNSSEC?
Date: Wed, 4 Dec 2024 20:57:47 -0600
Organization: TNet Consulting
Message-ID: <vir4rb$kfq$1@tncsrv09.home.tnetconsulting.net>
References: <67464f37@news.ausics.net>
 <vi68n4$k3r$1@tncsrv09.home.tnetconsulting.net>
 <wwva5dlul1r.fsf@LkoBDZeT.terraraq.uk>
 <vi8tkg$8ha$1@tncsrv09.home.tnetconsulting.net>
 <wwva5dj91v4.fsf@LkoBDZeT.terraraq.uk> <vim7jd$3t1l3$1@dont-email.me>
 <viobpa$s79$2@tncsrv09.home.tnetconsulting.net> <viod8c$fp5p$1@dont-email.me>
 <vion3k$fau$1@tncsrv09.home.tnetconsulting.net> <vioqhn$mcr7$1@dont-email.me>
 <viquuk$l6k$1@tncsrv09.home.tnetconsulting.net>
 <vir1jv$17csf$4@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 5 Dec 2024 02:57:47 -0000 (UTC)
Injection-Info: tncsrv09.home.tnetconsulting.net; posting-host="198.18.1.11";
	logging-data="20986"; mail-complaints-to="newsmaster@tnetconsulting.net"
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <vir1jv$17csf$4@dont-email.me>
Bytes: 3882
Lines: 66

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. . . .