On 2018-04-16 at 05:28 +0000, Brandon Long via mailop wrote: > 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.
In the HTTP Host header case, the hostname used is the one which the user typed in, or clicked upon. The name being validated is the name directly supplied, without editing. If the name is wrong, that's outside the scope of the systems involved. In MX delivery without DNSSEC, if Eve injects an MX record: gmail.com. IN MX 1 my-spy-agency.example.org. then using the hostname from DNS means that the client will happily go talk to my-spy-agency.example.org, using that as the SNI, and validating against that same domain, then present back an "all's good here boss" status, saying that it's happily confirmed the identity of gmail.com in validation. The SNI identity should match the identity to be validated, else there's no point doing any validation. Having clients willing to send SNI which they're not willing to accept as a valid value for verification is broken. Since the client can't a-priori know which is which (legitimate gmail.com server or Other), when using hostnames from insecure DNS, the client shouldn't send SNI unless and until it has an identity which it's willing to validate. If using DANE, or if using MTA-STS where the hostname from DNS has been vetted against the whitelist from MTA-STS first, then everything changes and SNI becomes important. So Gmail's response here, since not validating, works and is as "valid" as any other, but reporting that the client is "broken" leads to concern that this mode might stop working in the future. Why am I concerned about the future here? Because Gmail shows no sign of deploying DNSSEC/DANE and instead going for MTA-STS. Since I've no desire to ever implement client support for race-to-the-bottom trust-everyone CA modes for federated store-and-forward, which is why DANE for SMTP outright rejects TLSA Usages 0 and 1, I'm not likely to ever implement client support for MTA-STS: it's a system with horrible degenerate second order security as postmasters in most places are pressured to "just fix it" and so have to trust every CA. MTA-STS is equivalent to DANE had DANE gone with only supporting TLSA Usages 0 and 1, rejecting 2 and 3, with recipient domains able to effectively mandate what certificate authorities other organizations must trust, when talking not just to them, but to everyone else too. This is actively dangerous for attempts to improve mail security. If I had any confidence of mail from me not being blackholed by the IETF, I'd participate there and voice objections. So, if Gmail's "please fix your client" is a sign that failure to "fix" something behaving correctly will result in failure to communicate in the future, I am concerned. Gmail is important enough to warrant manual overrides in my system to keep their checks placated, so it's "what's needed to placate". If on the other hand "please fix your client" will remain in perpetuity, then ... *shrug* I can roll with it and just remove the manual override. I'd rather go in the direction of "manual override and able to validate" though. I no longer see that certificate in attempts to replicate. What's confusing to me, the next morning, is that included in the Gmail overrides is a force-enabling of validation (yes, using the CA system, but selective for remote domains where I choose to trust they're not going to press for a dodgy CA, and I'm still not happy at it). So for the mail to have gone through, that "CN=invalid2.invalid" certificate must have been issued by a CA in the public PKIX system. Which seems like a CA/Browser violation. Or perhaps there's a bug in my validation settings. -Phil
signature.asc
Description: Digital signature
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
