After reading all the discussion I posted an -02 which takes out all
mention of ESNI. Here's why.
The most important issue is process. ESNI is currently described only in
an early I-D which will not turn into an RFC for a long time. If I
reference it, this draft will be stuck behind ESNI, also for a long time.
If I don't, this draft should be able to progress quickly. Once it's
published, if you want to add an ESNI clause, you can do so by expert
review, no RFC needed.
I agree this is the most important issue, and is more than sufficient to
preclude mentioning it, but even if ESNI was to progress tomorrow and mail
systems were to implement it, I think there's a compelling case not to log its
use in trace fields.
More substantively, I would be surprised if any MTA ever implements ESNI
because it makes no sense for mail. On the web, different hostnames lead
to different web sites, and clients expect the name in the TLS cert to
match the hostname in the request. In mail, we've never expected the name
of the MTA to match the domain of the recpient, and it is quite normal for
a million different domains to point their MXes at the same host with the
same name, e.g. aspmx.l.google.com.
If you don't want your SNI to give anything away, you just do what mail
systems have done all along, use the same MX names for everyone. There's
no problem for ESNI to solve and certainly no reason to go to the effort
to put all the ESNI glop in the DNS.
I suggested this approach in an earlier response. But the counterargument was
that you can't assume any particular certificate naming model for SMTP in
general. I think that's a stretch, but once again even if it were true and ESNI
were to deploy to address some case we're missing in mail, I don't
think we can assume that any future use of ESNI would necessarily
correlate with whether or not to put SNI information in trace fields.
ietf-smtp mailing list