Currently, the record has a checksum at the front which would allow rejection of malformed records.
However, I think it is likely we will stop using TXT. -Ekr On Mon, Dec 3, 2018 at 12:24 PM Viktor Dukhovni <[email protected]> wrote: > On Mon, Oct 22, 2018 at 10:19:54AM -0700, [email protected] wrote: > > > https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-02 > > I see that the TXT record does not carry any sort of distinguishing > identifier in front of the payload: > > $ dig +short txt _esni.www.cloudflare.com > > "/wHdTAKgACQAHQAgnkJCWxSqQ75Vaxti1Q/S2XEbZa49aRA5/wtNLK2yA38AAhMBAQQAAAAAXAGIsAAAAABcCXGwAAA=" > > Given widely deployed wildcard (mostly SPF) TXT records implementations > need to be prepared to ignore responses that are not well-formed > base64 encodings of the expected data structure. Perhaps a short > leading identifier such as "ESNI;" or similar would make it easier > to quickly reject non-ESNI RData. > > For example, Rapid7's "mta-sts" survey dataset contains over a > million TXT records with owner name "_mta-sts.<domain-suffix>", but > only O(100) are actual "v=STSv1" MTA-STS TXT records, the rest are > largely SPF. So one can't rely on the "_esni" prefix to be an > effective indication of intent to provide an actual ESNI response. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
