> 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 _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta