> On Oct 23, 2017, at 12:24 PM, Ivan Ristic <ivan.ris...@gmail.com> wrote:
>
> There's another angle to take into account: SNI is mandatory to implement in
> TLS 1.3:
>
>
> https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.9.2
>
> For better or worse, SNI is part of TLS, and has been for more than a decade.
> IMO, all new standards should assume SNI by default and disable it only if
> there are very strong reasons.
MTI is not always the same as mandatory to use. Is it actually
required to be used? SNI would clearly be used for the policy
retrieval (HTTPS), but is not an obvious requirement for MTA-to-MTA
SMTP. There has to be a reason other than cargo-cult to send it.
That's what we're discussing. Mere analogies to HTTP are rather
weak I'm afraid.
MTAs are not browsers or Web servers and have a very different
history and model of TLS deployment[1]. SNI is presently largely
unused with MTA-to-MTA SMTP. RFC7672 requires servers that
implement DANE to continue with a default chain on receipt of
an unrecognized SNI name. Perhaps the same could be an explicit
requirement for SMTP-STS, otherwise sending SNI could cause more
harm than good.
--
Viktor.
[1] On the other hand this model is substantially more effective
at protecting a larger share of the traffic from passive attacks,
see https://transparencyreport.google.com/safer-email/overview
where we see that ~89% of email traffic to/from Google is TLS
encrypted. Last I looked HTTPS was reported at around 50% of Web
traffic.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
