I always thought of SNI has the equivalent of the Host HTTP header, so it should be the hostname you're connecting to.
That's my reading of rfc 6066 at least, and what Gmail expects. I admit that the limited statement about sni in rfc 7817 is kind of ambiguous since the document describes doing certificate validation against either the email domain or the connection hostname. I'm not sure how this not being protected by dnssec is any worse, sure the remote server could serve a cert that matches the sni, but if the cert doesn't validate, it's not valid. The protection is the cert signing authority. Brandon On Sun, Apr 15, 2018, 6:55 PM Phil Pennock <mail...@spodhuis.org> wrote: > While double-checking logs after an MTA update, I saw something from > Gmail which is ... bemusing. I'm wondering if there's any consensus on > how this should be handled in a manner which scales, given that Gmail > don't publish DANE records? > > 2018-04-16 01:14:55 [95041] 1f7sjN-000Oiu-7W > => <censored>@gmail.com > F=<censo...@spodhuis.org> > P=<prvs=064468e5c1=censo...@spodhis.org> > R=outbound_signed T=remote_dksign > H=gmail-smtp-in.l.google.com [108.177.119.26]:25 > I=[94.142.241.89]:59754 > X=TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256 CV=no > DN="/OU=No SNI provided; please fix your client./CN=invalid2.invalid" > K C="250 2.0.0 OK q15si10692445edd.343 - gsmtp" QT=1s DT=0s > > What SNI do folks feel should be sent, for TLS on MX delivery, when DANE > is not in use? Gmail has MTA-STS, but that's not even a published > standard yet, and not using SNI for a client not supporting SNI seems > "eminently sane" to me. Further, I don't see anything in > draft-ietf-uta-mta-sts-15 saying how the SMTP clients should choose > which hostname to send in SNI. > > I've overridden properties for delivery of mails for @gmail.com to > specify tlssni=gmail.com, which results in getting back the sort of DN > which I recall seeing in the past: > > DN="/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mx.google.com" > > but this is not scalable to all the other domains which outsource email > provision to Google. Nor to all the other mail providers. > > Should this be regarded as a sign that pressure is going to increase to > have clients implement MTA-STS, and so have some kind of https client > embedded in/alongside the MTA? > > Should clients be switching to always providing SNI matching the domain, > and never reusing an SMTP connection opened to a valid MX host for mails > to recipients in other domains which use that same MX? > > Or is the expectation that clients send an SNI matching the hostname of > the MX record, as per DANE, even though without DNSSEC that becomes > untrustworthy data? That seems to me to be a security blunder to be > strenuously avoided: DANE can _only_ impose that requirement because of > DNSSEC. > > Have I missed a draft/RFC somewhere which is spelling this out for the > non-DANE non-DNSSEC case? > > Thanks, > -Phil > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
