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. Cheers, S. > > Regards, > John Levine, [email protected], Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta >
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
