From: invalid@invalid.invalid   
      
   Grant Taylor  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/   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)