I suggest calling out ESNI specifically as a reason to not log the
SNI in the security considerations, e.g. via:
OLD:
In a few
circumstances, a new Additional-registered-clause might disclose
information to a recipient that was otherwise unavailable.
NEW:
In a few
circumstances, a new Additional-registered-clause might disclose
information to a recipient or other actor (via data leaks) that
was otherwise unavailable. In particular, if the SNI value was
encrypted in the TLS handshake [ESNI] then logging is NOT
RECOMMENDED.
[ESNI] would point at draft-ietf-tls-esni
I don't see how this recommendation makes sense given the stated goals
of ESNI. As I understand it, the goal of ESNI is to keep observers of
the TLS connection from being able to determine the server identity via the
SNI information exchange, especially in cases where this is sensitive
information.
This does seem like something you'd want to do SMTP, given that there are an
adundance of servers out there handling many domains with multiple identities.
However, the draft also says:
The design in this document takes a different approach: it assumes
that private origins will co-locate with or hide behind a provider
(CDN, app server, etc.) which is able to activate encrypted SNI
(ESNI) for all of the domains it hosts. Thus, the use of encrypted
SNI does not indicate that the client is attempting to reach a
private origin, but only that it is going to a particular service
provider, which the observer could already tell from the IP address.
And this seems applicable as well, since MTAs handling traffic from many
clients is the rule, not the exception.
But the "hide in plain sight" aspect of this means that ESNI needs to be used
for everything on a given server, not just in cases where the domain needs to
be kept private. So if ESNI deploys in SMTP according to this model, it may
erase many/most of the benefits of this draft.
(I note that in SMTP the hide in plain sight aspect might be better implemented
by having shared MX host names between private and public domains - no need to
wait for TLS extension to be fully fleshed out and deploy.)
This limitation might be acceptable if the security considerations for on-wire
exposure are the same as for trace fields. But AFAICT they aren't even close to
comparable. With trace fields the risk is that they can potentially betray the
message's origins and transfer history to anyone who subsequently sees the
message. These concerns apply regardless of whether or not ESNI is used - and
remember that ESNI won't be available in SMTP for quite a while, if ever.
I think the better approach here is to say that SNI logging adds to the
information about the message's origins and history, and the same
considerations as to whether or not to include things like server IPs also
apply to SNI information.
As to whether or not ESNI is used, I actually think logging that is a bad idea,
as it doesn't really any anything useful that I can see and less is more when
it comes to this sort of stuff.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp