Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt

[John R Levine <[e-mail]>]

On Thu, 23 Jun 2022, Peter Saint-Andre wrote:
>>>> - section 3.2: I wondered why no mention of MTA-STS or
>>>>     DANE? Could/should we say that MTA implementations
>>>>     SHOULD include support for such strictness?

> Hi John, thanks for sharing these insights. I'll reach out to a few Comcast 
> colleagues regarding DANE. We the authors of course want to recommend what's 
> best current practice, thus the interest in how widely deployed these 
> technologies are. Another wrinkle is that MTA-STS is specific to the email 
> world, whereas DANE has at least been defined as a more generalized 
> technology and deployment might vary across application protocols (e.g., I 
> know there has been some adoption of DANE in the XMPP community but it is far 
> from ubiquitous).

Among the reasons that DANE in e-mail is less common is that it is tricky. 
Until MTA-STS and DANE, when a mail server started a TLS session it could 
and usually did present a random self-signed certificate and nothing 
checked it.  But now it has to present a cert that matches the name that 
the client expects.

It is very common for a single mail server to handle mail for a zillion 
different domains.  Sometimes all the MX records point to the same name 
for the mail server, e.g.. all of Gmail's hosted domains point to 
aspmx.l.google.com., but sometimes each domain has its own name, e.g. the 
MX for tucows.com is mx.tucows.com.cust.hostedemail.com.  This means the 
mail server has to have a cert for every name that points to it and use 
SNI to return the correct one.  I added SNI to my mail server and have a 
library of 100 certs for the 100 domains it handles but as you know I am 
strange.

Regards,
John Levine, [e-mail], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly