Re: [ietf-smtp] [Uta] New Version Notification for draft-levine-addition

On 25/01/2019 16:36, John R Levine wrote:
> > 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.
> Naah, it just means they upgraded to a new library version that supports
> it.
No. That's not how ESNI works with the current draft, nor
how I guess it'll evolved. The TLS server (MTA in this case)
has to publish a key share and other stuff in the DNS for
ESNI to work and has to keep the DNS content and TLS server
config in-whack. So merely upgrading a library won't turn on
ESNI, it needs specific action from some admin-like being.

> Here's a thought experiment: try and construct a plausible Received
> header that would tell you more about the recipient with SNI than
> without, keeping in mind that the IP address of the server is mandatory,
> and the server name and recipient (the "for" clause) are usually
> included.  I think you'll find it's quite hard unless you do things that
> MTAs don't normally do.
If an MTA acts for loads of domains on one IP address using
different certificates via ESNI where the names in those
certificates aren't easily mapped to other message content.
I'm not claiming that'd be highly sensitive but it does
answer your question as more information is revealed. (If
more information were not revealed then you'd not even want
this new header field value, right?)

Again though I am not arguing for widespread use of ESNI in
SMTP here, just that if someone has decided to use ESNI, we
don't unexpectedly leak the value that they've chosen to try
not expose.

Cheers,
S.

0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp