> On Jan 25, 2019, at 4:38 PM, Stephen Farrell <[email protected]>
> wrote:
>
> 2. The new text in s4 is wrong, a mail server will generally
> have access to the value from ESNI or the h/s will likely fail,
> and the TLS server will treat that as the SNI to use for server
> certificate selection. The issue isn't that the server can't
> see the ESNI value, just that it oughtn't pass it on. So for
> example you might do this:
>
> OLD:
>
> If the SNI information in a STARTTLS negotiation is exchanged in
> encrypted form [ESNI] a mail server would generally not have access
> to the SNI, and can only log that ESNI was used.
>
> NEW:
>
> If the SNI information in a STARTTLS negotiation is exchanged in
> encrypted form [ESNI] a mail server SHOULD only log that ESNI was
> used, and not the actual name used.
Yes, to the extent that mail servers are at all likely to implement
support for ESNI on both ends of the connection (I don't expect to
do that in Postfix any time soon), the receiving system would still
primarily be working with the "decrypted" SNI. So indeed the text in:
4. Security Considerations
[...]
If the SNI information in a STARTTLS negotiation is exchanged in
encrypted form [ESNI] a mail server would generally not have access
to the SNI, and can only log that ESNI was used.
is due to an incomplete understanding of (the yet to be specified) ESNI.
Like John, I am very skeptical about the applicability of ESNI to SMTP.
The sender's MSA is generally stable over long time scales, and is easily
deduced from the sender's email address. The names of SMTP relays have
little bearing on user privacy. If one is to make a priority of sender
privacy, one would focus on not recording the submission IP address.
Hiding the well known MSA or SMTP relay name is not worth the trouble.
--
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
