[Top] [All Lists]

Re: [ietf-smtp] [Uta] New Version Notification for draft-levine-additional-registered-clauses-00

2019-01-25 10:47:33

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

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.


Attachment: 0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature

ietf-smtp mailing list
<Prev in Thread] Current Thread [Next in Thread>