Subject: [Uta] Interaction between MTA-STS and DANE

From: Ivan Ristic <[email-masked]>
Date: Thu, 12 Oct 2017 10:01:53 +0100

In re-reading the spec, I noticed that the spec, as it's written now,
effectively forbids DANE authentication, which may or may not be what you
wanted.

I am thinking about a scenario in which I outsource my email to a
third-party. Let's assume that I don't have DNSSEC on my domain name
user.com but that the provider does on their provider.com. Consequently,
their SMTP servers (mx.provider.com) might conceivably have self-signed
certificates that rely on DANE for validation.

MTA-STS is still useful in this case because it prevents MITM from
manipulating the MX servers that are allowed to receive email for user.com.

I've read the DANE language in the spec that says that MTA-STS doesn't
override DANE. That's fine. But should a MTA-STS-aware client fail a sever
with a non-public certificate that's DANE-validated? I think the answer is
probably yes, but perhaps that should be explicitly stated in the spec.

This is also an area where the current hostname matching might interfere
with DANE, because DANE is validated for the specific hostname that you're
connecting to, and all other hostnames in the certificate are ignored.

-- 
Ivan

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 12 Oct 2017 11:53:56 +0200

In the scenario you describe (in which the MX servers have certificates
that are not CA-validated), MTA-STS is simply not applicable.

I think your point is that it could be useful to allow MTA-STS to be used
in this case (because the recipient domain may not have DNSSEC but the MX
domain may), which is fair, but I suspect esoteric and not worth the
additional complexity, for a few reasons. First, big providers tend to be
the ones who find it harder to deploy DNSSEC, not small personal domains,
so the scenario you describe is, I think, not so common. But it's also the
case that supporting a "mixed" mode like this is quite difficult; what does
"mode=report" then do in "TLSA" usage? What does a sender who can do CA
validation but not DNSSEC validating resolves do? The complexity this
introduces is severe. (If you read back on the list archives, the early
drafts of this proposal *did* support DNSSEC/TLSA validation of MXs as an
alternative to CA, but we removed this to reduce the unneeded complexity!)

I'm not sure I follow your point about hostname validation. Is your point
that MTA-STS may consider a given MX to be valid (due to one of the SANs
matching the pattern in the policy) but DANE may not? That's certainly
possible, but a non-issue; it's up to deployers to not send conflicting
signals if they deploy both DANE and MTA-STS, no?

On Thu, Oct 12, 2017 at 11:01 AM, Ivan Ristic <[email-masked]> wrote:

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>
>

---

From: Ivan Ristic <[email-masked]>
Date: Thu, 12 Oct 2017 11:16:18 +0100

> alternative to CA, but we removed this to reduce the unneeded complexity!)

I think I agree with your assessment. I just think it would be better to
clearly say "MTA-STS is not designed to be used with DANE". Otherwise, you
will inevitably get people attempting to use it. Well, that will probably
happen anyway, but you'd at least be able to point them to the spec :)

> signals if they deploy both DANE and MTA-STS, no?

Sorry, I should have made it more clear. I was using the conflict to give a
supporting example for the conversation in the other thread.

The custom MX hostname validation in MTA-STS conflicts with DANE, not
because it's DANE, but because it does way differently from everything else
in TLS. In TLS, you decide which host you want to connect to, then you
validate the connection is valid for that hostname.

So my point would be that there may be other conflicts that we're not aware
of, and that TLS/PKI may evolve in a direction that creates new conflicts
in the future.

-- 
Ivan

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 12 Oct 2017 13:37:27 +0300

> validate the connection is valid for that hostname.

It does not just conflict with DANE, it also conflicts with some TLS
client APIs. And I would imagine that authors of such APIs would _not_
be supportive of additions to support nonstandard name matching (I
can certainly say I am not).

Furthermore, it is not compatible with sending SNI either. There are
servers out there that will outright abort on unknown SNI, and the SNI
specification explcitly states this as one of recommended outcomes,
with note that trying to continue probably won't work.

-Ilari

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 12 Oct 2017 13:03:25 +0200

> happen anyway, but you'd at least be able to point them to the spec :)

It *can* be so used. Of course, if you publish an MTA-STS policy that is
invalid, senders who validate MTA-STS may not deliver mail to you,
similarly if you publish a TLSA record for your MX that is invalid. I would
not say anyone has to choose one *or* the other, especially since that may
limit their ability to secure mail to their domain (since some senders may
only validate DANE and some may only validate MTA-STS). We do not want to
tell people to make a choice, do we?

> with note that trying to continue probably won't work.

To be clear, the specification suggests SNI as useful for *policy* hosting
(on the HTTPS endpoint), not MX matching. There's not a direct relationship
between SNI on the MTA-to-MTA connection and the MX identity verification,
except insofar as that if SNI is used, the MX just has to return a
certificate which matches the policy, same as if SNI is not used.

I will respond more thoroughly on the other thread, though, to keep these
two points separate.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 Oct 2017 11:31:56 -0400

> On Oct 12, 2017, at 5:01 AM, Ivan Ristic <[email-masked]> wrote:
> 
> In re-reading the spec, I noticed that the spec, as it's written now, effectively forbids DANE authentication, which may or may not be what you wanted.

This is reading is IMHO largely incorrect.  DANE SMTP for domains with
DNSSEC-insecure MX records is an optional best-effort mechanism that
is still vulnerable to active attack.  Once a domain has insecure MX
records, any TLSA records that may be found for some of its MX hosts
can be neutralized by an active attack that forges the MX RRset.

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

   Since the protocol in this memo is an Opportunistic Security protocol
   [RFC7435], the SMTP client MAY elect to use DANE TLS (as described in
   Section 2.2.2 below), even with MX hosts obtained via an "insecure"
   MX RRset.  For example, when a hosting provider has a signed DNS zone
   and publishes TLSA records for its SMTP servers, hosted domains that
   are not signed may still benefit from the provider's TLSA records.
   Deliveries via the provider's SMTP servers will not be subject to
   active attacks when sending SMTP clients elect to use the provider's
   TLSA records (active attacks that tamper with the "insecure" MX RRset
   are of course still possible in this case).

You seem to be looking for a way for the STS policy to be just an alternative
to  DNSSEC validation of the MX RRset, without reliance on the Web PKI for
authentication of the MX hosts.  However, any STS client is already reliant
on the WebPKI for obtaining the STS policy, so it may as well go ahead and
use Web PKI all the way.  The provider is almost certainly going to deploy
something signed by one of the usual CAs, even when TLSA records are also 
published.

And, as Daniel observed, smaller domains can be much more agile in deploying
DNSSEC, so if their provider has TLSA records, the client domain that wants
to use DANE should just turn on DNSSEC and not bother with STS.

It *would* be nice some movement by more of the large providers towards
supporting DANE *outbound*, which does not require any changes to their
own domains.  This would also help to flush out the small residual set
of domains that have broken TLSA records (or broken DNSSEC denial of
existence), but don't seem to care, because at present most senders
aren't affected.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 Oct 2017 11:48:56 -0400

> But should a MTA-STS-aware client fail a server with a non-public certificate
> that's DANE-validated?

I would expect a sending MTA to figure out which of DANE or STS applies to a given
delivery, and apply just that mechanism, and not some hybrid.  When DANE applies
(secure MX records and secure TLSA records for the MX host) then DANE is used and
STS is out of scope.  Otherwise, if an STS policy applies to the domain, then go
with that.  So that, by the time STS policy is being used, non-public certificates
would fail absent DANE.

> This is also an area where the current hostname matching might interfere with DANE,
> because DANE is validated for the specific hostname that you're connecting to,

1.  DANE for SMTP also requires support for multiple names, where the names are:

	* The nexthop domain (the recipient domain or explicitly configured gateway)
        * CNAME expansion of the nexthop domain
        * The TLSA base domain (either MX hostname full CNAME expansion or
          the original MX hostname, whichever yields the first secure TLSA RRset)

2.  The STS policy name matching is out of scope when DANE is in use.

You seem to be looking for STS policy to harden MX lookup, for use with DANE.
Such a mixed model is unlikely to be useful.  We could arguably *require*
STS clients to support DANE outbound, and then allow STS policies to express
"use DANE for my MX hosts" [ and that would be cool with me :-) ], but without
that, the domain in question would be broken for STS clients that don't support
DANE unless all the MX hosts had valid Web PKI certs, so just go with that...

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 Oct 2017 11:58:20 -0400

> On Oct 12, 2017, at 6:16 AM, Ivan Ristic <[email-masked]> wrote:
> 
> I think I agree with your assessment. I just think it would be better
> to clearly say "MTA-STS is not designed to be used with DANE".

These are alternative transport security mechanisms, I don't think
any such statement is necessary or desirable.  "STS used with DANE"
has no meaning, since STS specifies Web PKI for both the policy
distribution and the peer MTA authentication.

> Otherwise,
> you will inevitably get people attempting to use it. Well, that will
> probably happen anyway, but you'd at least be able to point them to the
> spec :)

There are not that many MTA implementations that matter.  Users can't
enable random policies that their MTAs don't implement.  I would not
expect any mainstream MTA to implement some STS-DANE hybrid mode.

An MTA might implement a "require security" setting that can be applied
to a destination, and would be satisfied with either of DANE or STS, but
at any given time it should be only one or the other, and not some hybrid.

-- 
-- 
	Viktor.

---

From: Anders Berggren <[email-masked]>
Date: Fri, 13 Oct 2017 15:33:33 +0200

> On 12 Oct 2017, at 17:31, Viktor Dukhovni <[email-masked]> wrote:
> 

After some of our users (one of which have 1.5M+ customers) enabled DANE ~one year ago, they’ve indeed had to maintain pretty large (at times), and ever changing, bypass lists (even after the large DNS providers fixed their TLSA responses). As you mentioned, the most common cause we’ve seen is broken DNSSEC proof for NODATA/NXDOMAIN, and firewalls filtering TLSA queries. Since a few weeks, we're experimenting with a shared list https://danefail.org https://github.com/danefail/list for our customers, but hopefully it’ll not be needed in the near future. Many of the domain owners and/or providers that we’ve contacted fixed their TLSA/DNSSEC issues within a few days after reporting.

--
Anders Berggren
Halon

---

From: Ivan Ristic <[email-masked]>
Date: Fri, 13 Oct 2017 16:19:12 +0100

On Thu, Oct 12, 2017 at 12:03 PM, Daniel Margolis <[email-masked]>
wrote:

> not say anyone has to choose one *or* the other, especially since that
> may limit their ability to secure mail to their domain (since some senders
> may only validate DANE and some may only validate MTA-STS). We do not want
> to tell people to make a choice, do we?
>

I am sorry, I couldn't find where SNI is mentioned in the MTA-STS spec;
could you point me to the relevant section?

More importantly, I think MTA-STS should mandate SNI usage. It's taken the
HTTPS world many years to finally approach the point where virtual secure
hosting is possible. Given that MTA-STS is opt-in, I think SNI should be
mandatory. Otherwise anyone offering mass-email hosting will be in a world
of pain, having to resort to splitting traffic across IP addresses.

> two points separate.
>
> On Thu, Oct 12, 2017 at 12:37 PM, Ilari Liusvaara <
> [email-masked]> wrote:
>

-- 
Ivan

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 13 Oct 2017 21:32:15 +0000

On Fri, Oct 13, 2017 at 03:33:33PM +0200, Anders Berggren wrote:

> After some of our users (one of which have 1.5M+ customers) enabled DANE
> ~one year ago, they've indeed had to maintain pretty large (at times),
> and ever changing, bypass lists (even after the large DNS providers fixed
> their TLSA responses).

Can you quantify "pretty large"?  Your list on Github is quite short...

> As you mentioned, the most common cause we've seen
> is broken DNSSEC proof for NODATA/NXDOMAIN, and firewalls filtering TLSA
> queries.

My fairly comprehensive survey of 4.6 million DNSSEC domains only
finds O(200) email domains where DNSSEC denial of existence would
hamper email delivery, and most of these are parked or otherwise
unlikely to be popular email destinations.

> Since a few weeks, we're experimenting with a shared list
> https://danefail.org https://github.com/danefail/list for our customers,

This list is not large, just 26 domains, of which 5 no longer have
issues when I test:

    labella-eindhoven.nl
    pluk-bloemen.nl
    appeldoorn-riooltechniek.nl
    schoorsteenvegerij-feije.nl
    jeroenappel.nl

It seems jsr-it.nl have resolved some problems, though 59 jsr-it
domains are still bad.  Of the remaining 21, 16 were on my list,
but 5 were new, thanks:

    autohopperleidschendam.nl
    ketel-dokter.nl
    rvhautos.nl
    vanderheijdenbouw.nl
    tre-pr.jus.br

The "jus.br" domain is a hornet's nest of DNSSEC breakage, so that
last one is not at all surprising.  I've not yet had much luck in
finding useful jus.br contacts to notify.  I already had:

    tse.jus.br
    tre-ap.jus.br

Plus not on your list:

    trtrj.jus.br
    tre-ce.jus.br
    tre-sp.jus.br
    tre-pb.jus.br
    tjrs.jus.br

I see you also have "truman.edu", which is the oldest entry on my list,
and continues to remain there despite multiple notices since 19-Nov-2014.
Some receiving systems don't yet care [feel enough pain] :-(

> but hopefully it'll not be needed in the near future. Many of the domain
> owners and/or providers that we've contacted fixed their TLSA/DNSSEC issues
> within a few days after reporting.

Ditto for the domains I've found, but the problem rate is rather
modest across a large population of domains (200 out of 4.6 million).
But the the original point, if large providers enable DANE outbound
and delay or bounce mail to probem domains I would expect the
problem to self-correct.

Feel free to confirm DNSSEC breakage for the additional 136 domains
immediately below my signature and add them to your list if your
observations match mine.  A few might have problems with a subset
of their nameservers, so the issues can be intermittent.  A large
fraction may be parked, but I don't consider domains whose SMTP
servers are non-responsive, so these have at least one live MX host
(possibly implicit in the absence of MX records).

The second list of 128 domains below the first lists domains with
working DNSSEC, but with either incorrect TLSA records, or no
STARTTLS (as seen from my server).  You can test both DANE and
certificate chain failures with:

    https://github.com/vdukhovni/danecheck

(If you have trouble getting the danecheck code built, I am interested
in curating more helpful build instructions for various platforms,
so please get in touch).

-- 
	Viktor.

# TLSA lookup failure
sispace.at
askerbeyli.az
cert.az
cgicustomerservice.biz
brmaster.com.br
emktcerto.com.br
m3ganet.net.br
cmscollegefrancais.ca
acct-admin.com
act85.com
amazon-awcs.com
cgicustomerservice.com
collegefrancais.com
conso-acteur.com
domains-dnssec.com
goofybynature.com
gwinnettmusic.com
lease-admin.com
netwerkevent.com
pfsc.com
servicerplus.com
swwu.com
terre-ysera.com
thesandiegos.com
varilease-invoicing.com
vrcinvestigations.com
workwizz.com
electrochmelar.cz
gurmanunicov.cz
hvideo.cz
kotatko-kamenivo-kura.cz
mflight.cz
talka.cz
thmotormedia.cz
zeleneauto.cz
sdutilities.de
okplus.dk
lmrsbkhome.eu
magicbus.fr
ic3.gov
calamar.hu
centrumimplant.hu
hungariansontrack.hu
ppko.hu
tulipankemping.hu
gorontaloprov.go.id
admings.net
b2.net
cleansendertracking.net
collegefrancais.net
keltia.net
mcso.net
akdesigns.nl
amsterdam-trouwringen.nl
appeldoornriooltechniek.nl
autoverhuurleidschendam.nl
bartox.nl
bomenrooibedrijfkuijpers.nl
bqr-club.nl
bqrc.nl
bt-cars.nl
btcars.nl
cober-goudsmeden.nl
cober-trouwringen.nl
code-lab.nl
comfortconnexion.nl
denhaagautoverhuur.nl
dobrebopolskie.nl
dutch-devotion.nl
dwarsfluitlesalmere.nl
erotheek-cupido.nl
erotheekcupido.nl
fampruim.nl
gezondwesterpark.nl
gootchy.nl
groenemaatschappij.nl
gsmshopspijk.nl
handgemaaktesieraden.nl
handgemaaktetrouwringen.nl
heboma-bouwmachines.nl
houtart.nl
ibleurope.nl
klusbedrijfdejong.nl
kuijpersbomenrooibedrijf.nl
leukegroepsuitjes.nl
mh-glasfolie.nl
mijntommy.nl
mijnwuzzi.nl
misterhealthy.nl
moj-best.nl
mojbest.nl
mondharmonicales.nl
nac-ua.nl
noddeveltpaarden.nl
noddeveltrubberenrvs.nl
particulieralarm.nl
pebbles.nl
platformbrabant.nl
praktijk-deberk.nl
pubermuur.nl
quadforumnederland.nl
reclameprodukten.nl
remotesim.nl
rk-design.nl
rk-designs.nl
rkdesign.nl
ronniekrijger.nl
runacademy.nl
schoorsteenveger-haarlem.nl
schoorsteenvegerijfeije.nl
sexshop-eindhoven.nl
simbi.nl
stroomconnectie.nl
studentenverdienenmeer.nl
timmersrijen.nl
tommyalert.nl
uitgaans.nl
vastgoed-hypotheken.nl
videoalarmservices.nl
wuzzi.nl
wuzzialarm.nl
wuzzialert.nl
wuzzimonitor.nl
xnyhps.nl
zakelijkeadministratie.nl
zngd.nl
cgicustomerservice.org
degner.org
peacepilgrimage.org
sprinzing.org
washingtonexclusive.org
foretagarcentrum.se
nsysu.edu.tw
mof.gov.tw
littlebluecar.co.uk
cleansendertracking.us

# TLSA verification failure or lack of STARTTLS
search.at
dipietro.id.au
dnschecker.be
it.be
stansoft.bg
gna.ch
sca.ch
smartmx.ch
4nettech.com
abanto-zierbena.com
abantoyciervana.com
andbraiz.com
arcanetides.com
avarty.com
bindlestickphotography.com
digitalwebpros.com
domaine-ala.com
gedankenausbruch.com
hirther.com
ismadgeintrouble.com
jeremyness.com
kaisers-backstube.com
kkeane.com
madgeandpaul.com
madgeisawesome.com
mykolab.com
nctechcenter.com
nevodnet.com
paulandmadge.com
pieterpottie.com
polymathematician.com
qooshi.com
rnrfunco.com
sgt.com
smia-automotive.com
sylvieandpieter.com
sylviesfollies.com
tntmonitoring.com
arbogard.cz
bels.cz
completeconsulting.cz
fks-roudnice.cz
ilustrat.cz
nfx.cz
petg.cz
pointaart.cz
zionbit.cz
apachedemo.de
bi9.de
juergenhecht.de
manima.de
ocmenzel.de
smartmx.de
supersahnetorten.de
thorko.de
1pc.es
0pc.eu
antoineducret.eu
cesidianroot.eu
gamepixel.eu
juergenhecht.eu
palinet.eu
smartmx.eu
subse.eu
vdlaken.eu
xenobite.eu
familledavid.fr
mc-fr.fr
quentindavid.fr
servmail.fr
kraus.global
demongeot.info
nonoserver.info
kd2.io
mxbackup.io
rapidfuse.io
kraus.is
lsd.is
lapenas.lt
laukas.lt
lius.lt
magistras.lt
datenknoten.me
giesen.me
rootbox.me
ahrain.net
avarty.net
castleturing.net
cherrypet.net
duffau.net
efflam.net
freeservices.net
misbegotten.net
oostergo.net
rk-mail.net
rnrfunco.net
wfbrace.net
castle.network
cbrace.nl
kamikazekippetjes.nl
lajetee.nl
lococensus.nl
myzt.nl
nuj-netherlands.nl
solarisinternetgroep.nl
steelyard.nl
abanto-zierbena.org
abantoyciervana.org
datacentrix.org
framkant.org
konundrum.org
pean.org
amadigi.ovh
efflam.ovh
itaskmanager.ovh
mail-jetable.ovh
skyneaker.ovh
damicris.ro
pasion.ro
testgeomed.ro
familie-sander.rocks
shevaldin.ru
ankerstal.se
brygg.se
jails.se
labbrack.se
rostit.se
ducret.sh

---

From: Binu Ramakrishnan <[email-masked]>
Date: Sat, 14 Oct 2017 00:30:57 +0000 (UTC)

> More importantly, I think MTA-STS should > mandate SNI usage. I believe you are referring to HTTPS MTA-STS policy distribution service, and do no see any reason not to include SNI requirements in the spec.

Sent from Yahoo Mail for iPhone

On Friday, October 13, 2017, 8:19 AM, Ivan Ristic <[email-masked]> wrote:

On Thu, Oct 12, 2017 at 12:03 PM, Daniel Margolis <[email-masked]> wrote:

I think I agree with your assessment. I just think it would be better to clearly say "MTA-STS is not designed to be used with DANE". Otherwise, you will inevitably get people attempting to use it. Well, that will probably happen anyway, but you'd at least be able to point them to the spec :)

It can be so used. Of course, if you publish an MTA-STS policy that is invalid, senders who validate MTA-STS may not deliver mail to you, similarly if you publish a TLSA record for your MX that is invalid. I would not say anyone has to choose one or the other, especially since that may limit their ability to secure mail to their domain (since some senders may only validate DANE and some may only validate MTA-STS). We do not want to tell people to make a choice, do we?

To be clear, the specification suggests SNI as useful for policy hosting (on the HTTPS endpoint), not MX matching. There's not a direct relationship between SNI on the MTA-to-MTA connection and the MX identity verification, except insofar as that if SNI is used, the MX just has to return a certificate which matches the policy, same as if SNI is not used.

I am sorry, I couldn't find where SNI is mentioned in the MTA-STS spec; could you point me to the relevant section?
More importantly, I think MTA-STS should mandate SNI usage. It's taken the HTTPS world many years to finally approach the point where virtual secure hosting is possible. Given that MTA-STS is opt-in, I think SNI should be mandatory. Otherwise anyone offering mass-email hosting will be in a world of pain, having to resort to splitting traffic across IP addresses.

I will respond more thoroughly on the other thread, though, to keep these two points separate. 
On Thu, Oct 12, 2017 at 12:37 PM, Ilari Liusvaara <[email-masked]> wrote:

-Ilari

______________________________ _________________
Uta mailing list
[email-masked]
https://www.ietf.org/mailman/l istinfo/uta

______________________________ _________________
Uta mailing list
[email-masked]
https://www.ietf.org/mailman/ listinfo/uta

-- 
Ivan_______________________________________________
Uta mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/uta

---

From: Anders Berggren <[email-masked]>
Date: Sat, 14 Oct 2017 15:34:15 +0200

> On 13 Oct 2017, at 23:32, Viktor Dukhovni <[email-masked]> wrote:
> 
> Can you quantify "pretty large"?  Your list on Github is quite short…

Thank you for the comprehensive and very helpful answer, and sorry for saying large without context. The total number of domains were larger than I expected; for example 144 (at its peak) at one site. 

> unlikely to be popular email destinations.

Agreed. The issue of DANE failure domains haven’t demotivated our customers from doing DANE verification.

>    schoorsteenvegerij-feije.nl

Thank you for pointing that out; we should run our cleanup script more often.

> ...

I really appreciate this. I’ll definitely take a look, mainly to confirm breakage and see if any of our customers have seen traffic to those domains.

Thanks,
Anders

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 16 Oct 2017 23:29:38 +0200

I was referring to section 6.2, "Policy Delegation":

   Second, the Policy Domain must point the "well-known" policy location
   to the hosting organization.  This can be done either by setting the
   "mta-sts" record to a host or CNAME specified by the hosting
   organization and by giving the hosting organization a TLS certificate
   which is valid for that host...

We don't call out SNI specifically, but presumably a hosting organization
who wants to host policies for multiple clients would do so with SNI.

I think we may be talking about different things, however. This is about
using SNI for hosting the policy (which is already HTTPS). I don't believe
SNI brings any value for the MXs themselves (i.e. the SMTP connection). In
fact, I can't think of any case where someone would want that. Can you give
an example where it would be desirable, or where not supporting SNI would
force a provider to split traffic?

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 16 Oct 2017 22:48:22 +0000

On Mon, Oct 16, 2017 at 11:29:38PM +0200, Daniel Margolis wrote:

> This is about

RFC7672 (SMTP Opportunistic DANE TLS) specifically requires SNI
for the SMTP STARTTLS handshake.  This is because the MX hosts used
by some domains are CNAME aliases (despite requirements to the
contrary) and CNAMEs are broadly supported by MTAs.  As a result,
we sometimes find either of:

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

	example.com. IN MX 0 smtp.example.com.
	smtp.example.com. IN A 192.0.2.1 ; Same as...
	smtp.provider.net. IN A 192.0.2.1

In such cases, the provider may need to be able to present a
certificate for the client's domain.

Note, I am not saying that it is a good idea to alias provider MX
hosts with vanity names from the client domain, indeed I typically
advise against this, and yet it is done with some frequency.

So it may be prudent to clarify whether STS is compatible with this
deployment model.  Perhaps STS can require that the default (sans
SNI) certificate provided by the MX host match the policy.  And
thereby rule out potential SNI-dependence.

Two examples:

    lesando.network. IN MX 10 mail.lesando.de.
    mail.lesando.de. IN CNAME mail.ud13.udmedia.de.

    jachthavenwolderwijd.nl. IN MX 20 mail.wolderwijd.nl.
    mail.wolderwijd.nl. IN CNAME mx1.bit.nl.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 17 Oct 2017 12:05:32 +0200

Hmm. OK. I don't know why people want vanity MX hostnames, but I guess they
do. ;)

In any event, what is there to clarify? STS doesn't change the behavior of
the MTA with respect to SNI at all, after all; we merely impose constraints
on what certificates must be presented irrespective of SNI. What's the
interaction here to clarify?

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 17 Oct 2017 11:22:55 -0400

> On Oct 17, 2017, at 6:05 AM, Daniel Margolis <[email-masked]> wrote:
> 
> In any event, what is there to clarify? STS doesn't change the behavior of the MTA with respect to SNI at all, after all; we merely impose constraints on what certificates must be presented irrespective of SNI. What's the interaction here to clarify?

Before DANE or STS certificate verification failure is ignored, so
no SNI need be sent.  Thus, for example, with unauthenticated
opportunistic TLS Postfix does not send SNI, and even enables
and prefers anon-(EC)DH ciphersuites, which send no certificates
at all (sadly, these go away with TLS 1.3).

With DANE, when TLSA records are published, and authentication
failure skips the MX host (deferring mail when no other MX hosts
remain), because the published TLSA record could be associated
with a non-default certificate chain, SNI is required to be
sent and must be the "TLSA base domain"[1].

With STS, there is now a choice:

   1.  Require the default certificate to match a/the MX
       hostname from the policy (is the matching staying
       the same or is it changing back based on recent
       feedback?) and client transmission of SNI is optional
       (perhaps even discouraged).

   2.  Require STS clients to send the MX hostname as the
       SNI domain, in case the remote MTA has multiple TLS
       personalities. [2]

By far the majority of domains do not use vanity MX hostnames,
so option 1 is a plausible constraint on would-be STS domains,
they'd have to stop using aliases, and use the same MX hostname
as all the other customers of the provider.

If however, we want to be cautious and assume that such vanity
names are there for good reason, and that providers should be
combine STS with SNI-mediated virtual-MX hosting, then SNI
will need to *always* be sent by STS clients, or else the
STS policy will need to specify a new attribute that signals
when SNI is required.

-- 
	Viktor.

[1] The TLSA qname sans "_25._tcp" prefix, which is either the
full MX hostname CNAME expansion or the raw MX hostname, whichever
is both lies in a DNSSEC signed zone and has TLSA records. See
https://tools.ietf.org/html/rfc7672#section-2.2.3

[2] The Exim SMTP server supports SNI, and IIRC I'd seen at least
one domain use it, but this is not easily discovered in my survey
database as I don't presently make separate non-SNI connections
to each host so there is no record of whether SNI was needed to
elicit the correct certificate.

---

From: Ivan Ristic <[email-masked]>
Date: Wed, 18 Oct 2017 09:39:03 +0100

Viktor, thanks for the pointer to RFC 7672. Their section 8.1 covers SNI,
and I propose to add something similar to MTA-STS.

Requiring SNI support in MTA-STS clients (for both HTTP and SMTP traffic)
doesn't force any particular server/certificate deployment model. It just
ensures that the target host is included in the TLS handshake via the SNI
extension. It's up to the server to decide whether it wants to use that
information or ignore it. It's extra information that can be ignored.
Better to have it and not use it, then not have it but need to use it.

The only intention here is to avoid deployment of MTA-STS without SNI,
which would effectively make it impossible to ever use it! It took the
HTTPS world a decade to get over that problem, having to wait for Windows
XP to die away. Inability to use SNI held back mass-virtual hosting and
SaaS service because setting up hosting required networking changes and
dedicated IP addresses. It was a huge mess.

I'll take a go at the possible wording, drawing from RFC 7672:

"To ensure that the server sends the right certificate chain, the SMTP
client MUST have support for the TLS SNI extension. When connecting to a
HTTP server to retrieve the MTA-STS policy, the SNI extension MUST contain
the domain name that hosts the policy. When connecting to an SMTP server,
the SNI extension MUST contain the ??? domain name.

HTTP servers used to deliver MTA-STS policies MUST have support for the TLS
SNI extension and MAY rely on SNI to determine which certificate chain to
present to the client. In either case, HTTP servers MUST respond with a
certificate chain that matches the policy domain name or abort the TLS
handshake if unable to do so.

SMTP servers MUST have support for the TLS SNI extension and MAY rely on
SNI to determine which certificate chain to present to the client. 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 MTA-STS TLS clients may be 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."

I made the wording above so that it's compatible with the current MX
filtering process. If we do end up changing it, we'll need to update the
wording. Also, we need to figure out what hostname will be placed in the
SNI extension: the hostname of the MX server itself or the recipient domain
name. As it stands, I suppose the latter.

-- 
Ivan

---

From: Ivan Ristic <[email-masked]>
Date: Wed, 18 Oct 2017 10:17:03 +0100

...

> Also, we need to figure out what hostname will be placed in the SNI
> extension: the hostname of the MX server itself or the recipient domain

Apologies for replying to myself, but the latter makes no sense. When
connecting to an SMTP server, the SNI extension should contain the hostname
of the intended MX server. If someone wants a vanity MX server they can use
a CNAME to ensure that the correct hostname is sent via TLS.

-- 
Ivan

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 18 Oct 2017 21:29:26 +0200

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.

Ivan, thanks, the wording seems reasonable to me.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 18 Oct 2017 15:39:37 -0400

> 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.

---

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

On Wed, Oct 18, 2017 at 8:39 PM, Viktor Dukhovni <[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.
>
> leak, since SNI is sent in the clear.

Not in practice. If you're not using vanity MX, it's obvious where the
email is going. Without SNI, if you want vanity MX you'll need a separate
IP address, so it's again going to be obvious from a network observer
perspective.

>   So one could take the view that

-- 
Ivan