Deutsch   English   Français   Italiano  
<wwvfrn2y0sy.fsf@LkoBDZeT.terraraq.uk>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!news.mixmin.net!sewer!alphared!2.eu.feeder.erje.net!feeder.erje.net!feeds.news.ox.ac.uk!news.ox.ac.uk!earthli!nntp.terraraq.uk!.POSTED.tunnel.sfere.anjou.terraraq.org.uk!not-for-mail
From: Richard Kettlewell <invalid@invalid.invalid>
Newsgroups: comp.misc
Subject: Re: [LINK] Calling time on DNSSEC?
Date: Thu, 05 Dec 2024 08:46:37 +0000
Organization: terraraq NNTP server
Message-ID: <wwvfrn2y0sy.fsf@LkoBDZeT.terraraq.uk>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: innmantic.terraraq.uk; posting-host="tunnel.sfere.anjou.terraraq.org.uk:172.17.207.6";
	logging-data="78793"; mail-complaints-to="usenet@innmantic.terraraq.uk"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Cancel-Lock: sha1:5O+P9V+nxwaHazP3BwikGrDp1NE=
X-Face: h[Hh-7npe<<b4/eW[]sat,I3O`t8A`(ej.H!F4\8|;ih)`7{@:A~/j1}gTt4e7-n*F?.Rl^
     F<\{jehn7.KrO{!7=:(@J~]<.[{>v9!1<qZY,{EJxg6?Er4Y7Ng2\Ft>Z&W?r\c.!4DXH5PWpga"ha
     +r0NzP?vnz:e/knOY)PI-
X-Boydie: NO
Bytes: 2672
Lines: 28

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/