jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-rescorla-tls-esni

Commentary: Instead of a Fronting SNI field , we should just re - use the Alt - Svc record , which already carries an SNI value to be used .
Paragraph (version A):
Also, servers operating in Fronting Mode SHOULD have DNS configured
to return the same A (or AAAA) record for all hidden servers they
service.
Paragraph (version B):
This structure is placed in the RRData section of a TXT record as
encoded above.  The name of each TXT record MUST match the name
composed of "_esni" and the query domain name.  That is, if a client
queries example.com, the ESNI TXT name is _esni.example.com.  Servers
SHOULD configure DNS such that, upon querying a domain name with ESNI
support, at most one A, AAAA, TXT ESNI, and ALTSVC I-D.schwartz-
httpbis-dns-alt-svc Resource Record is returned.  Alt-Svc records may
be used to inform the client of the plaintext (fronting) SNI.  Also,
servers operating in Fronting Mode SHOULD have DNS configured to
return the same A (or AAAA) record for all hidden servers they
service.
Draft: draft-rescorla-tls-esni

Commentary: maybe also point out that once you control DNS , getting a certificate is usually fairly easy
Paragraph (version A):
In comparison to I-D.kazuho-protected-sni, wherein DNS Resource
Records are signed via a server private key, ESNIKeys have no
authenticity or provenance information.  This means that any attacker
which can inject DNS responses or poison DNS caches can supply
clients with fake ESNIKeys.  This is not problematic since, without
ESNI, a DNS poisoning attacker can force clients to connect to IP
addresses and reveal their SNI in cleartext.  Alternatively, a DNS-
controlling attacker can strip the ESNI data from a response, thereby
causing clients to connect without ESNI in the usual way.  Thus,
doing so specifically for ESNI yields no new attack vectors.
Paragraph (version B):
In comparison to I-D.kazuho-protected-sni, wherein DNS Resource
Records are signed via a server private key, ESNIKeys have no
authenticity or provenance information.  This means that any attacker
which can inject DNS responses or poison DNS caches can supply
clients with fake ESNIKeys or strip the ESNIKeys from the response.
However, in the face of an attacker that controls DNS, no SNI
encryption scheme can work because the attacker can replace the IP
address, thus blocking client connections, or substituting a unique
IP address which is 1:1 with the DNS name that was looked up (module
DNS wildcards).  Thus, allowing the ESNIKeys in the clear does not
make the situation significantly worse.
Paragraph (version B):
Clearly, DNSSEC (if the client validates and hard fails) is a defense
against this form of attack, but DoH/DPRIVE are also defenses against
DNS attacks by attackers on the local network, which is a common case
where SNI encryption is useful.