On 25/01/2019 02:37, John R Levine wrote:
Even if this isn't a big leak, I think it's still worth preserving
a way in which SNIs don't leak - if the TLS client and server and
TLS client's DNS setup (and maybe the TLS server's too) are all
such that we've not leaked the SNI in any of those places then I
think we're better off if we can avoid leaking it here.
Since this is mail, I would expect that in the vast majority of cases,
the SNI will be the host name in the MX record of the recipient's
domain, which the recipient already knows. It's not like the web where
requests can come unsolicited from anywhere. If a domain has multiple
MXes, the IP address of the mail server is already in the Received
header so it's not hard to triangulate. The main thing the SNI clause
tells you is whether the client used SNI at all.
Your assumptions may or may not hold. The MTA can't tell. But it
can tell that ESNI was used. (Well, it's likely a TLS stack that
does ESNI will provide a way for the application to know ESNI was
used, but not certain.)
(Aside; I'd have no objection if "SNI=yes" was logged without
the name. Or "ESNI was used" or similar.)
We could have a larger discussion about redacting SMTP trace headers,
but not in this tiny I-D, please.
I agree. This discussion is about making a minor new logging
feature appropriately reflect how folks have configured their
systems, which is entirely relevant to this tiny I-D.
John Levine, johnl(_at_)taugh(_dot_)com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
Uta mailing list
Description: OpenPGP digital signature
ietf-smtp mailing list