Subject: [TLS] ESNI TXT RData, add leading distinguisher?

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 3 Dec 2018 15:23:52 -0500

On Mon, Oct 22, 2018 at 10:19:54AM -0700, [email-masked] 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.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Dec 2018 14:02:49 -0800

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-masked]>
wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>