On 25/01/2019 15:00, John R Levine wrote:
More to the point, though, I think you're overlooking two fundamental
differences between SNI in SMTP and in HTTP. On the web, only the
client making the request knows what web page she's looking for, and the
log info is saved on the server where random presumably hostile third
parties can look at it. In mail, neither of those are true.
By the nature of e-mail, the recipient of a message already knows who
the sender sent it to, since he or she got it. The Received headers go
into the message itself, not third party logs.
Mail list archives and mail corpus leaks do expose that to more
than one recipient.
So the recipient knwos
her MXes and the SNI doesn't tell her anything new about where the mail
went to or from. Even if you add forwarding scenarios, the existing
trace info is enough to tell what addresses the mail was forwarded
through and again SNI adds nothing new.
I think your argument above is more to the effect that ESNI isn't
so compelling for SMTP, and I'd agree that's reasonable.
But, if someone has decided to setup ESNI for an MTA (which will
need them to take action to do that), then I'd assume they have
a reason. At that point, exposing the ESNI value in the message
is what I'm arguing to not recommend.
(Aside; I'd have no objection if "SNI=yes" was logged without
the name. Or "ESNI was used" or similar.)
I wouldn't be opposed to adding that as an option, but I would not agree
that it would make a meaningful security difference.
If we agreed on a statement like "If ESNI was used then just
log the fact of usage and not the value" then I'd be fine.
I guess it'll be a rare enough case but I do think it's safer
as this new field is less likely to cause an unpleasant
surprise for someone for whom it turns out that using ESNI in
SMTP is a good plan.
Description: OpenPGP digital signature
ietf-smtp mailing list