Subject: [Uta] STS and SNI (was Re: Interaction between MTA-STS and DANE)

From: Daniel Margolis <[email-masked]>
Date: Thu, 19 Oct 2017 11:03:47 +0200

Yes, I also don't see the point of vanity hosts, but I guess some people
want this for some reason.

Ivan's language seems fine to me, for the most part, but I still wonder if
it wouldn't make STS implementation harder for MTA developers than the
alternative (which is to just say you can't use SNI with STS).

I don't see anyone else weighing in here, though, which makes me think
nobody cares too much about it. Let's see if changing the subject causes
renewed interest. ;)

On Wed, Oct 18, 2017 at 9:39 PM, Viktor Dukhovni <[email-masked]>
wrote:

>
>
> > On Oct 18, 2017, at 3:29 PM, Daniel Margolis <[email-masked]>
> wrote:
> >
> > Viktor, wearing your MTA-developer hat, any objections to requiring the
> MTA to always send SNI? I don't know what common MTAs do about sending SNI.
>
> At present, Postfix always sends SNI when doing DANE and never otherwise.
> The STS logic could be the same.  Mind you, SNI does introduce a privacy
> leak, since SNI is sent in the clear.  So one could take the view that
> the need for this is slim, and that the motivating use-case is not
> compelling.  Or one could support virtual-hosted "vanity" aliases for
> MX hosts.   Given DNS indirection from the domain to the MX hosts, the
> case for virtual-hosting with alternate chains is much weaker in SMTP.
>
> So I am reluctant to recommend SNI support for STS, but also not saying
> that it should not be supported.  I'd like to see the WG consider the
> pros and cons and choose accordingly.
>
> I'm fine with either outcome.
>
> --
>         Viktor.
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Jim Fenton <[email-masked]>
Date: Fri, 20 Oct 2017 18:09:16 -0500

> On Oct 19, 2017, at 4:03 AM, Daniel Margolis <[email-masked]> wrote:
> 
> Yes, I also don't see the point of vanity hosts, but I guess some people want this for some reason. 

Maybe this was explained somewhere earlier in the thread and I missed it, but can you explain what ‘vanity hosts’ are?

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 21 Oct 2017 15:40:58 -0400

> On Oct 20, 2017, at 7:09 PM, Jim Fenton <[email-masked]> wrote:
> 

An alternate name for an MX host that might require a non-default
certificate chain based on SNI.  For example, a customer example.org
of provider example.net might have:

	example.org. IN MX 0 smtp.example.org.
        smtp.example.org. IN CNAME smtp.example.net.

instead of the more direct:

	example.org. IN MX 0 smtp.example.net.

sometimes the customer will even alias the target IP address:

	; customer zone
	example.org. IN MX 0 smtp.example.org.
	smtp.example.org. IN A 192.0.2.1

	; provider zone
	smtp.example.net. IN A 192.0.2.1

This type of aliasing makes some sense for port 587 submission,
where changes may require reconfiguring MUA settings, but not
so much for inbound MX, and yet it is done in a small, but
perhaps non-negligible fraction of cases.

STS might require that this not be done, and it would likely
not be a major barrier to adoption.  Or this could be supported,
and client MTAs would send SNI to elicit the appropriate chain.

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Sat, 21 Oct 2017 18:22:05 -0500

> On Oct 21, 2017, at 2:40 PM, Viktor Dukhovni <[email-masked]> wrote:
> 
> 
> 

Thanks, Viktor; that explanation helped a lot.

One situation I can think of that might still require SNI is if two providers merged and combined their infrastructure. Example.com and example.net might each have 1000s of customers and it might not be practical for them to get the customers’ MX records updated in a timely fashion, so the same IP might need to handle requests for both domains for some period of time.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 21 Oct 2017 22:36:15 -0400

> On Oct 21, 2017, at 7:22 PM, Jim Fenton <[email-masked]> wrote:
> 

Yes, that's somewhat plausible, but on the the other hand one might
expect the providers to have sufficiently many IPs to not require
immediate consolidation onto a single pool of MX IP addresses.  They
can then migrate customers onto a common platform over time.
Or alternatively, they can deploy a certificate with multiple DNS-ID
subjectAltNames that matches both sets of names.

Thus, with SMTP there are workable alternatives to SNI.  The question
is how much flexibility to include in STS.

-- 
	Viktor.

---

From: Ivan Ristic <[email-masked]>
Date: Mon, 23 Oct 2017 17:11:05 +0100

> alternative (which is to just say you can't use SNI with STS).

Why would it make implementation harder? SNI has been widely supported for
a very long time in client libraries.

-- 
Ivan

---

From: Ivan Ristic <[email-masked]>
Date: Mon, 23 Oct 2017 17:24:08 +0100

There's another angle to take into account: SNI is mandatory to implement
in TLS 1.3:

https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.9.2

For better or worse, SNI is part of TLS, and has been for more than a
decade. IMO, all new standards should assume SNI by default and disable it
only if there are very strong reasons.

-- 
Ivan

---

From: Jeremy Harris <[email-masked]>
Date: Mon, 23 Oct 2017 17:26:08 +0100

> a very long time in client libraries.

Yet another callback to handle (both OpenSSL and GnuTLS, server side).
-- 
Jeremy

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 23 Oct 2017 18:28:08 +0200

Harder as in, per Viktor's comment, at least Postfix has special casing
around when to send SNI. So, more special casing. But you may be right that
this is just how it should be all the time.

All that said, the language you proposed seems reasonable to me. I'm happy
to try to work it in.

On Mon, Oct 23, 2017 at 6:24 PM, Ivan Ristic <[email-masked]> wrote:

>> Ivan's language seems fine to me, for the most part, but I still wonder
>> if it wouldn't make STS implementation harder for MTA developers than the
>>> > Viktor, wearing your MTA-developer hat, any objections to requiring
>>> the MTA to always send SNI? I don't know what common MTAs do about sending
>>> SNI.
>>>

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 23 Oct 2017 12:47:52 -0400

> On Oct 23, 2017, at 12:24 PM, Ivan Ristic <[email-masked]> wrote:
> 
> There's another angle to take into account: SNI is mandatory to implement in TLS 1.3:
> 
> For better or worse, SNI is part of TLS, and has been for more than a decade. IMO, all new standards should assume SNI by default and disable it only if there are very strong reasons.

MTI is not always the same as mandatory to use.  Is it actually
required to be used?  SNI would clearly be used for the policy
retrieval (HTTPS), but is not an obvious requirement for MTA-to-MTA
SMTP.  There has to be a reason other than cargo-cult to send it.
That's what we're discussing.  Mere analogies to HTTP are rather
weak I'm afraid.

MTAs are not browsers or Web servers and have a very different
history and model of TLS deployment[1].  SNI is presently largely
unused with MTA-to-MTA SMTP.  RFC7672 requires servers that
implement DANE to continue with a default chain on receipt of
an unrecognized SNI name.  Perhaps the same could be an explicit
requirement for SMTP-STS, otherwise sending SNI could cause more
harm than good.

-- 
	Viktor.

[1] On the other hand this model is substantially more effective
at protecting a larger share of the traffic from passive attacks,
see https://transparencyreport.google.com/safer-email/overview
where we see that ~89% of email traffic to/from Google is TLS
encrypted.  Last I looked HTTPS was reported at around 50% of Web
traffic.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 23 Oct 2017 10:00:05 -0700

> case for virtual-hosting with alternate chains is much weaker in SMTP.

The use of SNI does indeed introduce a privacy leak. However, the leak
only happens with "multiplexed servers", when a single server waiting
for connections at a single IP address can serve multiple "virtual
servers". In that case, the multiplexed server uses the SNI to direct
the connection to the context of the "virtual server", and then use the
appropriate certificate for that server. There is no real SNI leak when
the IP address corresponds to a unique server -- the SNI would contain
the string otherwise returned by "get host by address" or some
equivalent API. But there is leak when the server is multiplexed. Which
makes it a hard problem, because the multiplexed server needs to
identify the target virtual server, and needs to do that before
encryption keys are negotiated by TLS. The clear text SNI is the current
solution to the problem.

The TLS working group is well aware of this issue, and there is in fact
work in progress to address it --
https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/. Since
this is a really hard problem, you can expect progress to be slow.

As Viktor says, the easy way for STS is to avoid the "multiplexed
server" scenario. In fact, that's a pretty natural use of MX records.
The MX record for "some-personal-server.com" would point to
"mta.example.net", the SNI would be "mta.example.net", and the IP
address in the IP header would be that of "mta.example.net". The SNI
does not introduce a privacy leak in that scenario.

-- Christian Huitema

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 23 Oct 2017 13:21:38 -0400

> On Oct 23, 2017, at 1:00 PM, Christian Huitema <[email-masked]> wrote:
> 

In practice it would add a leak, because, for example, Microsoft has
a wildcard cert for *.mail.protection.outlook.com, and each hosted
domain has:

   example.com. IN MX 0 example-com.mail.protection.outlook.com

So while there is just one default certificate serving each of the
millions of hosted domains, the SNI would leak the exact name of
each domain.

-- 
	Viktor.

nist.gov. IN MX 0 nist-gov.mail.protection.outlook.com.
nist-gov.mail.protection.outlook.com. IN A 23.103.198.10
nist-gov.mail.protection.outlook.com. IN A 23.103.198.42
nist-gov.mail.protection.outlook.com. IN AAAA 2a01:111:f400:7d01::10
nist-gov.mail.protection.outlook.com. IN AAAA 2a01:111:f400:7d02::10
  nist-gov.mail.protection.outlook.com[23.103.198.10]
    TLS = TLSv1.2 with ECDHE-RSA-AES256CBC-SHA384
    name = mail.protection.outlook.com
    name = *.mail.eo.outlook.com
    name = *.mail.protection.outlook.com
    name = mail.messaging.microsoft.com
    name = outlook.com
    depth = 0
      Issuer CommonName = Microsoft IT SSL SHA2
      Issuer Organization = Microsoft Corporation
      notBefore = 2016-08-30T16:33:37Z
      notAfter = 2018-04-30T16:33:37Z
      Subject CommonName = mail.protection.outlook.com
      Subject Organization = Microsoft Corporation
    depth = 1
      Issuer CommonName = Baltimore CyberTrust Root
      Issuer Organization = Baltimore
      notBefore = 2014-05-07T17:04:09Z
      notAfter = 2018-05-07T17:03:30Z
      Subject CommonName = Microsoft IT SSL SHA2
      Subject Organization = Microsoft Corporation

---

From: Christian Huitema <[email-masked]>
Date: Mon, 23 Oct 2017 10:39:28 -0700

> millions of hosted domains, the SNI would leak the exact name of

Maybe add a discussion of this specific privacy issue in the draft? It
looks like the leak could be avoided by writing the records differently.
Do we understand why Microsoft and maybe others do that? Is there some
kind of tension between management and privacy?

-- 
Christian Huitema

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 23 Oct 2017 14:37:45 -0400

> On Oct 23, 2017, at 1:39 PM, Christian Huitema <[email-masked]> wrote:
> 

Perhaps they want to be able to locate the MX hosts for some customer
domains in a different datacentre based on customer requirements.  I
don't know whether traffic for "nist.gov" and "taipei.gov.tw" transits
the same servers, there could be demand for keeping both "on-shore".

Certainly, if SNI is deemed useful, some discussion might be warranted
in security considerations.  But we're not yet discussing whether on
balance SNI (to support vanity domains with virtual-hostring cert
selection) does more good than harm for MTA-to-MTA SMTP.

Once there's some perspective on whether SNI is sufficiently useful
to be desirable, we can ask whether the cost of that justifies the
privacy "leak".

In other words, who's depending on SNI to vend the right certificate
on port 25 inbound MX hosts?  Is their use case compelling?  We know
that vanity names are used, but they seem mostly cosmetic.  And
even (as with Microsoft) when an MX host has multiple names, all
the names match the same certificate (wildcard or multiple SANs),
so an actual hard requirement for SNI is not yet obvious to me.

I was hoping that some folks on this list would have some real
operational perspective, but so far I am the only one posting
data about actual deployments.  Perhaps the folks Google, Microsoft,
... would contact their operations and support teams and get a sense
of whether SMTP servers with multiple chains selected by SNI is
something they find they need to support.

Exim actually supports server-side SNI (mostly for port 587 I
expect), perhaps Jeremy could comment on whether Exim users
make real use of this to host multiple virtual TLS MX hosts
for port 25, and would really not want to just consolidate on
a single MX hostname.

In other words, where's the data that makes it possible to
understand whether SNI is actually useful, or mostly just
an auto-pilot design to look like virtual-hosting with HTTPS
where the requirements are very different.

-- 
	Viktor.

P.S.

  Some may notice that I failed to do the necessary research
  on this for RFC7672, and just assumed that SNI might be
  needed and chose to require it, just in case.  Sorry about
  that...  At the time I wanted above all else to maximize
  the chance that   an advertised TLSA record would match,
  and SNI could hypothetically be needed.  I did not consider
  proscribing such a dependency.  The same questions should
  have applied.

---

From: Ivan Ristic <[email-masked]>
Date: Mon, 23 Oct 2017 21:56:14 +0100

> where the requirements are very different.

Correct me if I am wrong, but at present no one checks if presented SMTP
certificates are valid. In fact, a major reason we need MTA-STS is to make
a clean start. You're not going to get the real-world data you're looking
for because why would anyone bother when all certificates are being
ignored, and MTAs downgrade to plaintext anyway.

SNI was not in SSL 3.0 and TLS 1.0 because back then there was no need for
it. And now, 20+ years, we have this:

https://developer.akamai.com/blog/2017/10/20/encrypting-web-need-support-tls-sni-remaining-clients/

The real question is how shall we protect email 20+ years from now. And, if
SNI is not mandated now, what hoops shall we have to go through to make
things right :)

Thus, my view is that MTA-STS should be a clean and robust protocol,
designed learning from mistakes of the past.

--

-- 
Ivan

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 23 Oct 2017 17:45:10 -0400

> On Oct 23, 2017, at 4:56 PM, Ivan Ristic <[email-masked]> wrote:
> 
> Correct me if I am wrong, but at present no one checks if presented SMTP certificates are valid. In fact, a major reason we need MTA-STS is to make a clean start. You're not going to get the real-world data you're looking for because why would anyone bother when all certificates are being ignored, and MTAs downgrade to plaintext anyway.
> 
> SNI was not in SSL 3.0 and TLS 1.0 because back then there was no need for it. And now, 20+ years, we have this:
> 
> The real question is how shall we protect email 20+ years from now. And, if SNI is not mandated now, what hoops shall we have to go through to make things right :)
> 
> Thus, my view is that MTA-STS should be a clean and robust protocol, designed learning from mistakes of the past.

These are generalities that ignore the specific issues at hand.
If we conclude that there's no need for virtual-hosting of TLS
(multiple chains at the same transport endpoint) with MTA-to-MTA
SMTP, then there's demonstrably no need for SNI, no matter how
much goodness it brings to the Web.

I still see no discussion of the use-cases that do or not motivate
the need for TLS virtual hosting with MTA-to-MTA (port 25) SMTP.
Let's not waste time on vague generalities.

Carping on TLS security in SMTP counter-productive, SMTP encrypts
a larger fraction of its traffic than the web does, precisely
because it is opportunistic.  Setting the bar too high can often
reduce overall security, RFC7435 is pertinent here.

-- 
	Viktor.

---

From: Ivan Ristic <[email-masked]>
Date: Mon, 23 Oct 2017 23:39:57 +0100

On Mon, Oct 23, 2017 at 10:45 PM, Viktor Dukhovni <[email-masked]>
wrote:

> > SNI was not in SSL 3.0 and TLS 1.0 because back then there was no need
> for it. And now, 20+ years, we have this:
> >
> >     https://developer.akamai.com/blog/2017/10/20/encrypting-
> web-need-support-tls-sni-remaining-clients/
> >
> > The real question is how shall we protect email 20+ years from now. And,
> if SNI is not mandated now, what hoops shall we have to go through to make
> things right :)
> >

Perhaps we don't agree with what's the specific issue at hand. For me, it's
the fact that you wish to go against the lessons-learned elsewhere, which
came at a very high cost. I made a point how 20 years ago others couldn't
perceive the need for SNI in TLS, knowing what they knew then. But you
responded to that with hand waving.

> much goodness it brings to the Web.

We can conclude that, and it may be true today, but it would still be
prudent to mandate SNI just so that it could be used at some point in the
future, should the need arise.

In other words, we accept that we don't know everything and design so that
our mistakes can be rectified.

If the group strongly believes there is a privacy issue with SNI that makes
it not acceptable, so be it. But I haven't seen other compelling arguments
against.

> because it is opportunistic.

Actually, virtually all important HTTP traffic is protected with not only
strong encryption, but also with certificate checking, HSTS, and even
public key pinning. In the meantime, anyone can downgrade an SMTP
connection to plaintext.

If SMTP is better at encrypting over HTTP, it's only because email is
concentrated in the hands of several big providers.

>   Setting the bar too high can often

-- 
Ivan

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 23 Oct 2017 19:27:07 -0400

> On Oct 23, 2017, at 6:39 PM, Ivan Ristic <[email-masked]> wrote:
> 
> We can conclude that, and it may be true today, but it would still
> be prudent to mandate SNI just so that it could be used at some point
> in the future, should the need arise.

Well, we are designing a standard for the foreseeable future, and some
crystal ball gazing is appropriate.  We should make a best-effort to
determine what might be reasonably useful, and produce a standard
that meets reasonable requirements, that is not bloated with
features that are unlikely to be useful or perform reliably.

Your past experience with the Web is a good reason to not dismiss
flexibility to lightly, so the issue is worth discussing, but it
does not justify SNI on merely a "we might need it some day" basis.
There really does need to be a reasonable use-case.

> In other words, we accept that we don't know everything and design so
> that our mistakes can be rectified.

Sometimes too many features are also a mistake that is hard to rectify.

> If the group strongly believes there is a privacy issue with SNI that
> makes it not acceptable, so be it. But I haven't seen other compelling
> arguments against.

All I'm saying is:  Let's discuss whether there's a plausible use-case
for SNI in MTA-to-MTA SMTP.  Not whether SNI proved to be needed for
HTTP.  HTTP lacks an equivalent of MX indirection, so the requirements
are different.

Who needs SNI for port 25 SMTP, are they a small minority and can they
make do without.  Is there significant customer demand, ...

This may be too tiresome, and perhaps the easy way out it to throw in
the kitchen sink so that the obstacle to progressing the draft goes
away, but that sadly leaves the questions unaddressed and the spec
potentially bloated with a pointless privacy leak.

I think that if Google, et. al. read the tea leaves, chatted with
some more email service operators (rather than TLS geeks like us)
there'd probably be a sensible answer to this question, and I for
one would go with whatever best matches expected needs.

-- 
	Viktor.

---

From: Jeremy Harris <[email-masked]>
Date: Tue, 24 Oct 2017 10:23:21 +0100

> for port 25, and would really not want to just consolidate on

I can't help on actual deployment numbers, sorry.

The one I personally operate is small enough to not need
VPS-equivalents;  I'm tempted to suggest that the combination
of DNS support (MX vs. A records) and the richness of
hop-by-hop email processing possibilities (developed ad-hoc
before and during the transition to the Internet) combined
with the less-harsh latency requirements on mail vs. browsing
make VPS' for email not needed.

As you say, the feature is there, in Exim.
It's agnostic about port-number and the purpose of the service.
-- 
Cheers,
  Jeremy

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 24 Oct 2017 12:10:57 +0200

I believe Google's MTAs are sending SNI. But the only time this would
matter would be for cases like
https://support.google.com/a/answer/2520500?hl=en, since ordinarily nobody
is validating identities on server-to-server SMTP.

Regarding arguments in favor of supporting SNI, Jim made the best attempt
in this thread to come up with a motivating use case, and I don't find it
very compelling. In his example (where two hosting providers merge
infrastructure), a) STS does not require that the hostnames actually match
the certificate presented (but only that the certificate match the
policy!), and b) even if the provider wants the hostname to match the
certificate, they can just use a single cert with multiple SANs to achieve
this.

To expand on this slightly, I believe the vanity hostname discussion was
(and my apologies for this) misleading. Even given Viktor's example

        example.com. IN MX 0 smtp.example.com.
        smtp.example.com. IN CNAME smtp.provider.net.

there's no need for SNI *or* a certificate that has multiple SANs (for
example.com and provider.net); the STS policy in all cases matches "
provider.net." The only reason to desire the certificate hostname to be "
example.com" is if example.com wants to have two different MX records
pointing at (say) provider1.net and provider2.com, and wants both to share
the "example.com" certificate--and even this is nonsensical, since they can
just have a policy that lists multiple acceptable "mx" patterns ("mx:
provider1.net, mx:provider2.com, mx: example.com", with the third thrown in
for safety!).

Ivan, you're definitely right that we may not be able to foresee all the
uses here, but I do think there are clear *differences* between HTTP and
SMTP that make the analogy imperfect. In HTTP, there are two specific
constraints not applicable to our use case which motivate SNI: first, the
hostname is a UI component in the browser, so when you have two different
organizations sharing a HTTP endpoint, they don't want to share a hostname;
second, the hostname is required to match the certificate. The first is not
true for SMTP (the MX hostname doesn't really matter in the UX) and the
second is not true for STS (the "mx" pattern constrains the certificate and
not the DNS record).

Regarding arguments against SNI, I don't think the privacy risk is
significant, or really a reason not to require SNI. The only case I see
where SNI introduces an actual privacy leak that wasn't present before is
the case of multi-tenant shared-IP hosting where instead you would use a
shared cert with multiple SANs. Otherwise, if (instead of SNI) you use
dedicated IPs, you of course have same privacy leak.

In short, I see neither strong arguments against SNI nor any particular
reason to support it. I agree with Viktor that we can just require it (with
Ivan's language) so as to move the spec forward and be future proof. That
sounds less than satisfying to me, but it's not something I'd lose sleep
over.

I'll try to ask around off-list about SNI usage. But a better motivating
example from the group here would probably also help the discussion.

Dan

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 24 Oct 2017 15:15:04 +0300

> sounds less than satisfying to me, but it's not something I'd lose sleep

One thing to be _very_ careful of is not to break SNI semantics. Which
include "one name, which has to be correct".

SNI assumes the web model, where there is only one correct name the
client wants to connect to. In fact, the specification has a note that
earlier drafts supported multiple names, but this was explicitly
dropped as not useful.

One way to do that with sending SNI would be:

- Check received MX (and SRV?) records against the policy (including
  the possible implicit MX). Discard all that do not match. If no
  targets remain, raise temporary error.
- Pick a mail exchanger from the remaining entries, look up its
  address, and connect with SNI being the target of the MX (or SRV?)
  record (without chasing CNAMEs).

And since SNI is intended for "one name" standard certificate name
validation scenario, this would also allow using the standard name
validation instead of the wildcard-to-wildcard matching.

There are a few problems with combining this with "vanity" names:
- One has to either break RFCs by pointing MX to a CNAME, or to
  shadow provoder addresses (I think some DNS provoders allow
  automatic address shadowing).
- If one wants balancing among multiple provoders, one needs multiple
  names.

An alternative I see would be to specify SNI values to use in policy.
Or not sending SNI values at all.

-Ilari

---

From: Ivan Ristic <[email-masked]>
Date: Tue, 24 Oct 2017 18:54:46 +0100

> very compelling.

I don't know, I think people will find good uses for it if it becomes
available. For example, here's one: virtual SMTP providers. One company
maintains the core infrastructure, others build businesses that focus on
branding, marketing, and support. Easy to do at scale with SNI, difficult
without. Just an idea.

That said, I of course agree that it's not the same as with HTTP.

-- 
Ivan

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 24 Oct 2017 13:54:52 -0400

> On Oct 24, 2017, at 8:15 AM, Ilari Liusvaara <[email-masked]> wrote:
> 

Actually, it does not have to be correct.  Postfix happily ignores
SNI and continues with the default certificate chain.  Indeed that's
true for every MTA that's using OpenSSL, unless it takes special
care to degrade service by paying ttention to SNI and objecting to
unexpected names.  By default the SNI signal from the client is
simply ignored.  Once again, SMTP is NOT HTTP.

> client wants to connect to.

No, it is just a hint to the server, that may help it to identify
the right chain.  See

    https://tools.ietf.org/html/rfc7672#section-8.1

   Each SMTP server MUST present a certificate chain (see [RFC5246],
   Section 7.4.2) that matches at least one of the TLSA records.  The
   server MAY rely on SNI to determine which certificate chain to
   present to the client.  Clients that don't send SNI information may
   not see the expected certificate chain.

   If the server's TLSA records match the server's default certificate
   chain, the server need not support SNI.  In either case, the server
   need not include the SNI extension in its TLS HELLO, as simply
   returning a matching certificate chain is sufficient.  Servers
   MUST NOT enforce the use of SNI by clients, as the client may be
   using unauthenticated opportunistic TLS and may not expect any
   particular certificate from the server.  If the client sends no SNI
   extension or sends an SNI extension for an unsupported domain, the
   server MUST simply send some fallback certificate chain of its
   choice.  The reason for not enforcing strict matching of the
   requested SNI hostname is that DANE TLS clients are typically willing
   to accept multiple server names but can only send one name in the SNI
   extension.  The server's fallback certificate may match a different
   name acceptable to the client, e.g., the original next-hop domain.

> In fact, the specification has a note that

Indeed only one hint can be sent, but it need to be an exact match.

>  record (without chasing CNAMEs).

This broken algorithm is precisely why I did not want to see MX
filtering in STS, and so we now only use the names for matching
not filtering.  It neglects to perform loop elimination (removing
all MX hosts worse than the sending host itself when it is one
of the MX hosts for the destination) before discarding names that
don't match the policy.

> validation instead of the wildcard-to-wildcard matching.

SNI is a means to signal the client's most preferred name to the
server.  The server can use that name to identify an appropriate
chain, or it can just ignore it, and should respond with a
default chain if it inspects the name and find no specific chain
for that name.  It is up to client to accept or reject the
certificate chain it ultimately receives from the server.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 24 Oct 2017 14:04:01 -0400

> On Oct 24, 2017, at 1:54 PM, Ivan Ristic <[email-masked]> wrote:
> 
> I don't know, I think people will find good uses for it if it becomes available. For example, here's one: virtual SMTP providers.

> One company maintains the core infrastructure, others build businesses
> that focus on branding, marketing, and support. Easy to do at scale with
> SNI, difficult without. Just an idea.

This is largely unnecessary.  Email users never see the "branding"
of MX hosts.  Users just see the destination domain.  The MX records
are only seen by unattended software.  The MX records can just point
at the appropriate infrastructure name.

Google and Microsoft already provide hosting to millions of domains
with just one certificate chain that directly or through a wildcard
matches all the MX hosts used to do so.

In Holland there was a recent merger between two hosting companies,
and at the conclusion a few thousand hosted domains updated their
MX records.  Maintaining multiple sets of legacy names and managing
multiple certificate chains going forward is more complicated than
working with the hosted customers to update their DNS.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 24 Oct 2017 14:12:56 -0400

> On Oct 24, 2017, at 1:54 PM, Viktor Dukhovni <[email-masked]> wrote:
> 

Correction: 

	s/need to .../need not .../ be an exact match.

-- 
	Viktor.

---

From: Ivan Ristic <[email-masked]>
Date: Tue, 24 Oct 2017 19:15:48 +0100

On Tue, Oct 24, 2017 at 7:04 PM, Viktor Dukhovni <[email-masked]>
wrote:

> available. For example, here's one: virtual SMTP providers.
>
> This is largely unnecessary.

No, it really is. If I am building a business on top of someone else's
infrastructure, I don't want to build on top of something I don't control;
in this case, their domain name. Thus, I don't want to give their MX
servers to my customers. It can be as simple as not wanting your users to
know that you're "reselling" someone else's service. It raises all sorts of
questions.

More importantly, once my customers configure their MX, getting them to
change their configuration would be not only impractical, but effectively
impossible. Asking them to change anything would at the very least be an
annoyance, lot of them would refuse, and lots of them would perhaps look
elsewhere.

At the same time, perhaps the business will want to switch to someone else
for the core infrastructure. Or, even, start managing its own
infrastructure.... and so on.

> Email users never see the "branding"

-- 
Ivan

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 24 Oct 2017 14:47:03 -0400

> On Oct 24, 2017, at 2:15 PM, Ivan Ristic <[email-masked]> wrote:
> 
> No, it really is. If I am building a business on top of someone else's infrastructure, I don't want to build on top of something I don't control; in this case, their domain name. Thus, I don't want to give their MX servers to my customers. It can be as simple as not wanting your users to know that you're "reselling" someone else's service. It raises all sorts of questions.

An MTA is far more heavy-weight infrastructure component than
a website.  Sure you can start a Web business on someone else's
shared platform, but running email hosting on someone else's
virtually hosted MTA is entirely unrealistic.

MTAs both send and receive email, they run complex anti-spam
and anti-virus filters, they are integrated with mailbox
stores, they have IP reputations as sending systems, they
do DKIM signing, add Authentication-Results headers, store
and forward email, ...

Mere SNI will not come remotely close to giving you a virtual
MTA.  An MTA is NOT a website.

-- 
-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Tue, 24 Oct 2017 13:48:37 -0500

> On Oct 24, 2017, at 5:10 AM, Daniel Margolis <[email-masked]> wrote:
> 
> Regarding arguments in favor of supporting SNI, Jim made the best attempt in this thread to come up with a motivating use case, and I don't find it very compelling. In his example (where two hosting providers merge infrastructure), a) STS does not require that the hostnames actually match the certificate presented (but only that the certificate match the policy!), and b) even if the provider wants the hostname to match the certificate, they can just use a single cert with multiple SANs to achieve this. 
> 

Regarding a) above: I apparently missed this. Is there any other circumstance where the certificate presented is matched against anything other than the hostname?

If we go forward with REQUIRETLS, this would require that it match against the STS policy if one is present, or against the hostname if one isn’t present. I haven’t yet fully thought through whether this has any security implications, but at first glance it seems like spoofing an STS policy where one isn’t present would be another way to cause REQUIRETLS to accept a certificate it shouldn’t.

-Jim

---

From: Ivan Ristic <[email-masked]>
Date: Tue, 24 Oct 2017 19:57:59 +0100

> do DKIM signing, add Authentication-Results headers, store

That's exactly why it's a great candidate for outsourcing. I will let
someone else do all of that techie stuff, and I'll focus on growing the
business.

> MTA.  An MTA is NOT a website.

No, SNI will give me freedom to migrate my stuff if I want to. If I can't
do that, I have no long-term business.

--

-- 
Ivan

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 24 Oct 2017 14:59:46 -0400

> On Oct 24, 2017, at 2:48 PM, Jim Fenton <[email-masked]> wrote:
> 
> If we go forward with REQUIRETLS, this would require that it match against the STS
> policy if one is present, or against the hostname if one isn’t present.

No.  If/when REQUIRETLS implies authenticated TLS and not just mandatory,
but possibly unauthenticated encryption, then the authentication mechanism
needs to be left to the sending MTA's choice, it might use DANE, STS, or
some future technology, and what exactly gets checked depends on the
mechanism.  So REQUIRETLS must NOT specify how authentication is done.

> I haven’t
> yet fully thought through whether this has any security implications, but at first
> glance it seems like spoofing an STS policy where one isn’t present would be another
> way to cause REQUIRETLS to accept a certificate it shouldn’t.

It should not be easy to "spoof" STS policy.  STS would be rather weak
if it were.  STS, for better or worse, is basically as strong as DV
certificate issuance.  Use DNSSEC and publish CAA records that only
allow CAs you trust to not issue certificates for your domain to
a rogue party.  I have:

$ dig +noall +ans -t caa dukhovni.org | grep issue
dukhovni.org.           3600    IN      CAA     0 issue "dukhovni.org"

as I don't presently use any of the public CAs.

-- 
-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 24 Oct 2017 15:11:44 -0400

> On Oct 24, 2017, at 2:57 PM, Ivan Ristic <[email-masked]> wrote:
> 
> On Tue, Oct 24, 2017 at 7:47 PM, Viktor Dukhovni <[email-masked]> wrote:
> 

Hosting email is *all that techie stuff*.  Email is infrastructure.
There's little else you offer by rebranding someone else's
infrastructure.  They can just sell the service directly and cut
out the unnecessary middle-man.

One might try to offer enhanced security, like say protonmail.ch,
but that's not possible on a shared platform...  Otherwise, email
is a commodity.

> No, SNI will give me freedom to migrate my stuff if I want to.
> If I can't do that, I have no long-term business.

In any case this business model is already dead in the water
given the market dominance of the existing hosting players,
who don't have to pay a third party for infrastructure.

An MTA requires a dedicated IP outbound to avoid reputation
damage from co-hosted miscreant third-parties.  Once you have
that, you may as well have a dedicated inbound IP and the need
for virtual hosting goes away.

Let's get back to hearing actual, not straw-man use-cases...

-- 
	Viktor.

---

From: Ivan Ristic <[email-masked]>
Date: Tue, 24 Oct 2017 20:35:40 +0100

Viktor, you're now discussing the viability of the business model. But,
just because you wouldn't attempt it, it doesn't meant that others
wouldn't.

The point was that SNI makes this particular business model possible.
That's all. Is it possible that you will accept that one point so that we
can perhaps discuss something more productive? You don't have to like (the
use case)!

There's probably a ton of small ISPs who might actually be interested in
doing exactly something like this. At least here in the UK, when you get an
Internet connection you also get a bunch of email addresses. Lots of ISPs
are near-virtual too. With my business hat on, I'd love to outsource
anything that I have no interest in, and that's never going to be my core
competency. Email is a commodity. With it taken care of, I can focus on
what's going to differentiate me from others.

-- 
Ivan

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 24 Oct 2017 15:51:45 -0400

> On Oct 24, 2017, at 3:35 PM, Ivan Ristic <[email-masked]> wrote:
> 
> Viktor, you're now discussing the viability of the business model. But, just because you wouldn't attempt it, it doesn't meant that others wouldn't. 

I am discussing *plausible* requirements, not hypothetical ones.

> The point was that SNI makes this particular business model possible.

I don't believe it does.  Shared hosting for non-cooperating separately
branded MTAs is not particularly plausible.

> 
> There's probably a ton of small ISPs who might actually be interested in doing
> exactly something like this. At least here in the UK, when you get an Internet
> connection you also get a bunch of email addresses.

And so pay a third party to do something for your users that generates no revenue
for you and that the users can get for free from Gmail, etc?

I'll leave it to the draft authors to determine whether a plausible or
compelling case for requiring SNI has been presented.

My final comment is a reminder that the privacy leak is not hypothetical at
least for Microsoft's hosted customers with MX hosts that have "example-com"
labels prepended to ".mail.protection.outlook.com".

-- 
	Viktor.

---

From: Brandon Long <[email-masked]>
Date: Tue, 24 Oct 2017 12:54:35 -0700

Google's MTA's send SNI, and we have used it for inbound smtp to provide
white label support for large GSuite customers.  It was more important for
MSA, but these customers all wanted that level of control at the MX level
as well.

Without SNI, we had to provision extra IP addresses, which are somewhat
constrained.  It also requires a lot more operational overhead, or a very
complicated network infrastructure such as that used by GCP and AWS that
involves programmable IPs/routing from the application stack.  Obviously,
white label also requires distributing signed certificates periodically,
which is also operational overhead, though again, the modern cloud systems
are having to implement all of that anyways.

The privacy leak seems pretty minor, ie at the Google level, it would only
provide you with knowledge of percentage of connections to each of our
white label customers.  The majority of mail is already large MTA to large
MX.  Sure, at the boutique or personal server level, it might provide a bit
more data, but if you're only handling mail for ~5 domains, knowing the
specific ones for a transaction seems pretty minor.  One shouldn't assume
that those that care don't have a copy of the world's DNS, and will know
what 5 MX records are pointed at your IP.

I agree that we should not exclude SNI usage, and we should probably
encourage it.

Brandon

On Tue, Oct 24, 2017 at 3:10 AM, Daniel Margolis <[email-masked]>
wrote:

> matter would be for cases like https://support.google.
> com/a/answer/2520500?hl=en, since ordinarily nobody is validating
> identities on server-to-server SMTP.
>
> pointing at (say) provider1.net and provider2.com, and wants both to
> share the "example.com" certificate--and even this is nonsensical, since
> they can just have a policy that lists multiple acceptable "mx" patterns
> ("mx: provider1.net, mx:provider2.com, mx: example.com", with the third
> thrown in for safety!).
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 24 Oct 2017 16:28:58 -0400

On Oct 24, 2017, at 3:54 PM, Brandon Long <[email-masked]> wrote:

> Google's MTA's send SNI, and we have used it for inbound smtp to provide white label support for large GSuite customers.  It was more important for MSA, but these customers all wanted that level of control at the MX level as well.

Thanks for that.  That's exactly the kind of information this
discussion needed.  The MSA case is indeed the more compelling
one, but it seems that some customers want this for MX too, and
once they've paid the logistical price of making SNI work for
submission, they sometimes choose to also employ vanity/white-label
MX hosts while they're at it.

In that case, SNI language à la RFC7672 section 8.1 might do the
trick.  If you like that enough, a reference to that might save
you the need to repeat the same text.

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Thu, 26 Oct 2017 18:21:21 -0700

> mechanism.  So REQUIRETLS must NOT specify how authentication is done.

I understand that's your position on REQUIRETLS but let's table that for
now and stick with MTA-STS.

The question I have is: Why are we matching the certificate against the
policy rather than against the hostname, and is that done in any other
context? Does that offer any additional flexibility? The draft
introduces a new wildcard-to-wildcard matching algorithm in section 3.5
that needs to be implemented, rather than more conventionally matching
certificate against hostname (and potentially using libraries that
already exist).

While client MTAs don't typically fail to negotiate TLS if there is a
certificate mismatch, at least some do check the certificate and log a
warning, so we're talking about requiring two different matching
algorithms depending on whether there is an STS policy or not.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 26 Oct 2017 21:35:34 -0400

> On Oct 26, 2017, at 9:21 PM, Jim Fenton <[email-masked]> wrote:
> 
> context? Does that offer any additional flexibility?

This was discussed when the change was made, and again in response
to Ivan's questions just in the past week or so.  The flexibility
in question allows the policy to specify that the certificate will
match (say) the recipient domain and not the MX hostname, or either,
or some unspecified hostname in a domain, leaving the match somewhat
fuzzy, which you describe as "wildcard to wildcard".

> The draft

At least one existing library, OpenSSL, widely used by MTAs, already
supports such matching.  Granted other libraries may not yet
have equivalent functionality.

> algorithms depending on whether there is an STS policy or not.

Similarly, for DANE one forgoes the entire PKI matching route and
compares certificates against TLSA records from DNS, and for DANE-TA(2)
records the the names in the certificate against any element of the
triple (TLSA base domain, recipient domain, CNAME expansion of the
recipient domain).  The triple may degenerate to a pair or singleton
for some domains.

-- 
	Viktor.

---

From: Alberto Bertogli <[email-masked]>
Date: Fri, 27 Oct 2017 17:39:16 +0100

> fuzzy, which you describe as "wildcard to wildcard".

Note that according to the analysis linked by Daniel [1], "only
0.6% of domains present trusted certificates that match their domain
name, while 34.2% present trusted certificates that match their MX
server".

So to me you are arguing to add a non trivial amount of complexity to
certificate validation, and make it differ significantly from widely
used and tested logic; in exchange for making it easier for <1% of the
hosts to potentially adopt STS.

I think that is a terrible tradeoff: the implementation complexity and
security risks are not worth the marginal benefit.

Thanks,
                Alberto

[1]: http://conferences.sigcomm.org/imc/2015/papers/p27.pdf