On Mon, Apr 16, 2018 at 10:05 AM Phil Pennock <mail...@spodhuis.org> wrote:
> 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. I will point out that we're talking about opportunistic TLS at this point, and if you're really concerned about individual opportunistic being more secure, then hard coding specific chains or such is typically how that's handled at this point. At this point, it is neither practical to support cert lookaside for ~millions of email domains, and even less practical to obtain and rotate such certificates. Having those domains protected against non-DNS MITM seems beneficial. With this and logging, one at least will have access to know if one has been MITM'd at an audit stage, even if the secrets are lost. > 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. I think this is an interesting stance, and I'm sure you've heard the objections to this before. You don't have to trust every CA, you certainly don't need to trust every CA for every host, and there are other tools to be used here such as cert transparency. Also, maybe at some point the popular DNS providers will have point & click DNSSEC and DANE configuration, until then, I believe it's much easier for end users to use MTA-STS. Note that at our last look, none of the popular providers allowed users to specify a TXT record large enough for a 2k DKIM key, for example. > 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. I'm not sure what you saw. If you're talking to a server with a lot of "hosts", then not sending an SNI should get you the "default" host, which should work for this case. We do have a lot of servers out there, so maybe some host is in a testing or canary config, or maybe that canary config was rolled back. I can ask our experts. Brandon _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
