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

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


Attachment: signature.asc
Description: Digital signature

mailop mailing list

Reply via email to