> On Apr 18, 2018, at 11:18 AM, Daniel Margolis <[email protected]> wrote:
>
> Thanks. I think this is consistent with what was added here:
> https://github.com/mrisher/smtp-sts/blob/master/mta-sts.txt#L633. If not, let
> me know.
Looks largely fine to me. I am not fond of the HTTP-specific dictum:
HTTP servers MUST respond with a certificate chain that matches the policy
hostname or abort the TLS handshake if unable to do so.
If that's what HTTPS requires generally, so be it, but if this goes beyond
HTTPS requirements, then I think the decision of whether to abort the handshake
belongs
with the client and NOT the server. If the client is willing to accept "the
wrong"
certificate, there's nothing the server can do about that. An attacker won't
abort the connection. Presenting a default certificate, when one that matches
the SNI is not available makes it much easier for the client to troubleshoot the
problem.
----
On a related note, it has just been brought to my attention that Gmail's SMTP
servers
refuse to negotiate TLS 1.3 when the connecting SMTP client offers TLS 1.3, but
does not send SNI, they instead negotiate TLS 1.2 and return a self signed
certificate instead of the usual CA-issued certificate. The subject DN is:
OU=No SNI provided; please fix your client., CN=invalid2.invalid
And yet, when SNI is presented, the same default CA-issued certificate is
returned regardless of the SNI value! While TLS 1.3 says that servers MAY
require SNI, and hence
that clients SHOULD send SNI, and SNI is mandatory to *implement*, it is NOT
mandatory to use.
Forcing a downgrade to TLS 1.2, and failing authentication to boot, for lack of
SNI seems rather counter-productive. Is there a good reason to do this?
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
