Subject: Re: [ietf-smtp] why are we reinventing mta-sts ?

From: "John R Levine" <[email-masked]>
Date: 6 Oct 2019 20:10:15 -0400

In article <[email-masked]>,
> ... If an MX record with target smtps- or starttls- isn't signed
> using DNSSEC, it's not clear that the client should trust the smtps- or
> starttls- prefix, and that the client should drop mail that can't be
> relayed that way.??...

What's wrong with MTS-STS defined in RFC 8461?

It's defined, it works, it's deployed at a lot of large mail systems.
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Claus Assmann <[email-masked]>
Date: Sun, 6 Oct 2019 17:23:48 -0700

> What's wrong with MTS-STS defined in RFC 8461?

It requires an HTTPS server, thus adding an extra service and moving
the "trust" problem to CAs (AFAICT).

---

From: Keith Moore <[email-masked]>
Date: Sun, 6 Oct 2019 20:30:04 -0400

> It's defined, it works, it's deployed at a lot of large mail systems. 

I hope MTS-STS turns out to be sufficient.   But I've seen so many 
attempted solutions fail for one reason or another that I don't think it 
hurts to discuss potential alternatives.

Keith

---

From: "John Levine" <[email-masked]>
Date: 6 Oct 2019 21:56:16 -0400

>the "trust" problem to CAs (AFAICT).

I was there when we were defining MTA-STS and the people involved,
who work for companies that probably handle the majority of all of
the mail in the world, did not want it to depend on DNSSEC for
deployment reasons.

See sections 2 and 10 of RFC 8461.

If you like DNSSEC, you can publish a DANE TLSA record for your SMTP
server, and systems like Comcast that pay attention to DNSSEC will use
it to check that you support TLS and have the right cert.

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 7 Oct 2019 11:11:06 +0200

I've only quickly skimmed the original thread, but it seems like the
argument is about this magic DNS prefix for MX records that would indicate
"this MX should offer STARTTLS", right?

As John says, the new proposal also requires DNSSEC, no? It seems like the
primary difference is that the new proposal is simpler by indicating only
that the server supports TLS, but not what identity it presents? Why is
that desirable?

On Mon, Oct 7, 2019 at 3:56 AM John Levine <[email-masked]> wrote:

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

-- 
How's my emailing? http://go/dan-email-slo

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Oct 2019 08:36:47 -0400

On 10/7/19 5:11 AM, Daniel Margolis wrote:

> argument is about this magic DNS prefix for MX records that would 
> indicate "this MX should offer STARTTLS", right?
>
> As John says, the new proposal also requires DNSSEC, no? It seems like 
> the primary difference is that the new proposal is simpler by 
> indicating only that the server supports TLS, but not what identity it 
> presents? Why is that desirable?

I didn't see this explicitly specified in the proposal, but IMO the 
server certificate should match the target of the MX record.

And depending on DNSSEC probably does impair the ability of this to be 
deployed.   But if DoT can be used instead of DNSSEC, it seems to me 
that this might be easier to deploy than MTA-STS.

Granted, MTA-STS exists already and enjoys some support.   A new 
proposal thus has a high bar to clear in order to be accepted as a 
standard.   But I don't think it's wrong to discuss other ideas.

Keith

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Mon, 7 Oct 2019 18:55:22 +0530

Hello Daniel,

I'm the original author of this prefix proposal. So I hope you don't mind
my input here.

If you have read my responses carefully, you might have noticed that I have
no issues with DNSSEC. In fact, I want DNSSEC to become popular.  The only
thing I don't like about DNSSEC is its complexity. Apart from that, I have
nothing against DNSSEC.

In the case of MTA-STS, I don't support it for the following reasons.

(1) End users have to spend money on buying SSL certificates, buying
hosting packages and then configuring those things.

(2) Even spending an extra $5/month is a big deal in developing countries.

(3) Not all end users have knowledge about how to configure an HTTPS
server. This is the reason why most of them relying on third party mail
hosting services like Gmail for hosting their mails. They can follow simple
things like adding a DNS record. But configuring an HTTPS server is going
to be a rocket science for them.

(4) Big companies like Google and Microsoft has millions of businesses in
their pocket to distribute the MTA-STS solution. So the end result will be
SMTP have to rely on HTTPS forever.

If you still need more reasons, this thread
<https://news.ycombinator.com/item?id=19628182>has some valid points.

-- 
Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Mon, 7 Oct 2019 19:03:12 +0530

Yes, I didn't explicitly mention that.

I worded like this.

Where “starttls-” says “Our port 25 supports Opportunistic TLS. So if
> STARTTLS command not found in the EHLO response or certificate is invalid,
> then drop the connection”.

Certificate becomes invalid when the protected MX target not found in the
certificate presented.

-- 
Best Regards,

---

From: "John Levine" <[email-masked]>
Date: 7 Oct 2019 09:46:12 -0400

>that this might be easier to deploy than MTA-STS.

But DoT and DNSSEC are unrelated.  DNSSEC promises that the data you
got are the ones that the authoritative servers published, even though
someone might have snooped on the way.  DoT promises that nobody
snooped and the data you got are the ones that the resolver, which may
be lying, sent.

You can have either without the other.  If you want confidentiality
and integrity, you need both.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Oct 2019 09:50:38 -0400

> snooped and the data you got are the ones that the resolver, which may

Clearly you can't trust the resolver.  But an answer to a DoT query to 
an authoritative server seems like it would be sufficient, provided 
there's assurance that the server really is authoritative.

Keith

---

From: Дилян Палаузов <[email-masked]>
Date: Mon, 07 Oct 2019 15:39:08 +0000

Hello,

On Mon, 2019-10-07 at 18:55 +0530, Viruthagiri Thirumavalavan wrote:
> (3) Not all end users have knowledge about how to configure an HTTPS server. This is the reason why most of them relying on third party mail hosting services like Gmail for hosting their mails. They can follow simple things like adding a DNS record. But configuring an HTTPS server is going to be a rocket science for them.   
> 

Much more people know how to configure an HTTPS server, than to configure a SMTP server (with STARTTLS).  So configuring
HTTPS is not an obstacle.  Since, soon or late a mail server operator will want to reject emails that fail DMARC
validation, the operator will have to learn DKIM.  Then set some custom email rules, AV/AS and so on.  Setting up HTTPS
(and a web-based mail client) looks trivial compared to the remaining pieces.

The HSTS (http strict transport security) preload list, https://hstspreload.org/, is knowledge in HTTP browsers, about
sites, which serve content explicitly over HTTPS.  Browsers use the knowledge and do not contact the hosts under the
listed domains over pure HTTP.

Similar to it, there is a MTA-STS (smtp strict transport security) preload list: a set of hosts, which can serve SMTP
over TLS.  The list is hosted at https://starttls-everywhere.org/ .  This list functions just like HSTS preload list,
but for port 25.

Talking about SMTP and TLS is bi-fold.  There are incoming and outgoing connections.  Depending on the MTA, setting up a
MTA that applies DANE for outgoing connections can be done very easily, so in the context of outgoing connections,
utilizing DANE/DNSSEC can be easier than MTA-STS.

Installing the MTA-STS preload list on the own MTA, and using it for outgoing connections, can be easier than
configuring MTA-STS for outgoing connections.

Deploying/enforcing DANE for outgoing connections is equally hard compared to deploying MTA-STS for outgoing
connections, when the used MTA offers neither features.

To sum up, the options in the MTA are:
* for outgoing connections:
  - check MTA-STS (without necessary publishing own MTA-STS records)
  - check DANE (without having deployed DNSSEC for the own domain)
  - check the STARTTLS-everywhere preload list for the destination host
  - consider sending your own certificate during establishing the TLS tunnel (nearly nobody does this)

* for incoming connections:
  - publish MTA-STS records
  - publish DANE records, once DNSSEC is set up
  - add an entry in the MTA-STS preload list

* for both: speak TLS 1.3 .

What are the pros and cons of sending the certificate of the SMTP client to the SMTP server, during STARTTLS?

Regards
  Дилян

---

From: "John Levine" <[email-masked]>
Date: 7 Oct 2019 12:28:24 -0400

>there's assurance that the server really is authoritative.

There's no such thing as a DoT query to an authoritative server (or
DoH for that matter.)  At this point you can only set up DoT by
private arrangement with your resolver.

There's been some discussion about how an authoritative server
might signal that it accepts DoT but it hasn't gotten very far.

R's,
John

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Mon, 7 Oct 2019 22:55:19 +0530

>
> Much more people know how to configure an HTTPS server, than to configure
> a SMTP server (with STARTTLS).  So configuring
> validation, the operator will have to learn DKIM.  Then set some custom
> email rules, AV/AS and so on.  Setting up HTTPS

We both use a different demographic to define "end user" for MTA-STS. The
way you see it, an end user is a "mail server operator".  The way I see it,
an end user is a "small business" who hosts their mails in a third party
mail service like Gmail. Configuring an HTTPS server is not going to be
easy for such small businesses.

This comment <https://news.ycombinator.com/item?id=19629569> portrays that
part more clearly.

I'd like to be wrong, but with the nature of this standard, I don't expect
> heavy adoption. If a person is deploying G Suite or Office 365 or similar,
> they get asked to setup MX records, TXT for SPF, possibly DKIM and so on.
> If I could create a record that says "use the policy Microsoft/Google
> publish", it would be a no brainer. And it would take off because, much
> like SPF, these groups can just add it to their onboarding checklist.
> As soon as you say "deploy an end point on your domain", it falls in the
> too hard basket for unimportant domains. Moreover, in a corporate situation
> the people running mail have no involvement in web endpoints. For the mail
> domains I professionally manage, that falls into the domain of another
> department, and the people involved in running web endpoints are going to
> say something like "if it was important, Wordpress would do it already for
> us".

On Mon, Oct 7, 2019 at 9:09 PM Дилян Палаузов <[email-masked]>
wrote:

> Much more people know how to configure an HTTPS server, than to configure
> a SMTP server (with STARTTLS).  So configuring
> validation, the operator will have to learn DKIM.  Then set some custom
> email rules, AV/AS and so on.  Setting up HTTPS
> The HSTS (http strict transport security) preload list,
> https://hstspreload.org/, is knowledge in HTTP browsers, about
> sites, which serve content explicitly over HTTPS.  Browsers use the
> knowledge and do not contact the hosts under the
> Similar to it, there is a MTA-STS (smtp strict transport security) preload
> list: a set of hosts, which can serve SMTP
> over TLS.  The list is hosted at https://starttls-everywhere.org/ .  This
> list functions just like HSTS preload list,
> but for port 25.
>
> Talking about SMTP and TLS is bi-fold.  There are incoming and outgoing
> connections.  Depending on the MTA, setting up a

-- 
Best Regards,

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Mon, 07 Oct 2019 13:30:30 -0400

> easy for such small businesses.

The obvious answer is, of course, to write the proposal such that the https server
can be outsourced the same way the email service was outsourced, and the DNS
service was outsourced to a DNS hosting company.

There's an obvious business opportunity for hosting the email, the DNS, the http, and
any other bits as one turnkey package.

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Mon, 7 Oct 2019 23:17:17 +0530

Yes that's a good idea to solve this problem. But then again, people still
have to pay money to make their mail secure. Not everyone would go for
that. We can't always go like "we already defined the MTA-STS standard. You
all have to live with it".

So there is nothing wrong in discussing the alternatives. As Keith said, a
new proposal need to have a high bar to become standard.  And if DoT is not
possible as John said, then my proposal still have a long way to go.

Thanks

-- 
Best Regards,

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Oct 2019 14:59:26 -0400

> On Oct 7, 2019, at 12:28 PM, John Levine <[email-masked]> wrote:
> 

Well, maybe this use case will provide an incentive for someone to do the remaining work.

Keith

---

From: "John R Levine" <[email-masked]>
Date: 7 Oct 2019 15:08:32 -0400

> Well, maybe this use case will provide an incentive for someone to do the remaining work.

If you can figure out a backward compatible way for authoritative DNS 
servers to signal that they support DoT without a lot of performance loss 
(e.g., a failed probe to port 853 on every query to a non-DoT server), a 
lot of people over in dnsop would like to hear about it.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Stan Kalisch" <[email-masked]>
Date: Mon, 07 Oct 2019 15:10:29 -0400

> any other bits as one turnkey package.

That may be, but I do not think, however, that this addresses Viruthagiri's assertion about the cost being prohibitive for some in developing countries.

Thanks,
Stan

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 7 Oct 2019 22:04:16 +0200

I'm interested to hear more about those situations.

It seems like the primary concerns with additional costs associated with
MTA-STS are

* the cost of buying a CA-signed cert (but what about Let's Encrypt?)
* the cost of hosting your own HTTP server if you are in a hosted
environment
* the cost of hosting an HTTP server if you are hosting your own MTA

Depending on the level of automation, I think the extra effort required by
MTA-STS ranges from "none" to, unfortunately, "some." But I don't fully
understand the scenario where it's a significant economic burden beyond the
basic cost of hosting an MTA. Can someone help explain this better?

On Mon, Oct 7, 2019 at 9:11 PM Stan Kalisch <[email-masked]>
wrote:

> That may be, but I do not think, however, that this
> addresses Viruthagiri's assertion about the cost being prohibitive for some
> in developing countries.
>
>
> Thanks,
> Stan
>

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Oct 2019 16:15:31 -0400

On 10/7/19 4:04 PM, Daniel Margolis wrote:

> But I don't fully understand the scenario where it's//a significant 
> economic burden beyond the basic cost of hosting an MTA.

Not that I disagree with you, but IMO the cost of all of these is too 
high.   In my part of the world it has unfortunately become conventional 
wisdom that public-facing services should be "outsourced", and too many 
people have forgotten that this was once unnecessary for services that 
did not see significant demand.   So I don't think the cost of hosting 
an MTA is nearly low enough and I am supportive of efforts to reduce it.

Keith

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Tue, 8 Oct 2019 02:07:17 +0530

> lot of people over in dnsop would like to hear about it.

How about adding a prefix or label just like our solution for the
authoritative DNS servers that support DoT?

ns1.example.com  =>  dot-ns1.example.com OR _dot.ns1.example.com

-- 
Best Regards,

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Oct 2019 16:50:03 -0400

On 10/7/19 4:37 PM, Viruthagiri Thirumavalavan wrote:

> ns1.example.com <http://ns1.example.com> => dot-ns1.example.com 
> <http://dot-ns1.example.com> OR _dot.ns1.example.com 
> <http://dot.ns1.example.com>

I was thinking more in terms of a new DNS RR type:

example.com      DOTNS ns1.example.com

And change DNS servers to return DOTNS records as additional information 
in the same circumstances as they return NS records.

That way the DOTNS records get automatically discovered in exactly the 
same way that NS records do.

Of course you want the DOTNS records to be signed with DNSSEC but this 
is less of a problem for RRs in TLD and SLD zones than it is for DNS 
zones in general.

Keith

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Tue, 8 Oct 2019 02:31:47 +0530

Hi Keith,

Your solution makes more sense.

Thanks.

On Tue, Oct 8, 2019 at 2:20 AM Keith Moore <[email-masked]>
wrote:

> Of course you want the DOTNS records to be signed with DNSSEC but this is
> less of a problem for RRs in TLD and SLD zones than it is for DNS zones in
> general.
>
> Keith
>
>
>

-- 
Best Regards,

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 7 Oct 2019 20:24:20 -0400

> basic cost of hosting an MTA. Can someone help explain this better?

Every supported service requires resources: personnel, expertise,
monitoring, disk, CPU, memory, bandwidth, security, etc.  Every
supported service increases the attack surface and thus increases
the aggregate risk.  In some environments, not only is all of this
expensive but it's administratively quite difficult.

---rsk

---

From: "John Levine" <[email-masked]>
Date: 7 Oct 2019 21:58:51 -0400

In article <[email-masked]> you write:
>> (3) Not all end users have knowledge about how to configure an HTTPS server. This is the reason why most of
>them relying on third party mail hosting services like Gmail for hosting their mails. They can follow simple
>things like adding a DNS record. But configuring an HTTPS server is going to be a rocket science for them.   
>> 
>
>HTTPS is not an obstacle.

Having actualy implemented mta-sts for the mail domains I host (about
85 of them) I can confirm that it's not difficult.  Setting up a
little web server is easy; if for some reason you're outsourcing your
mail to a provider that doesn't support mta-sts, it was a deliberate
decision to put the web server at a different name mta-sts.<name> so
you can point it at some random $5/yr web host if you need to.

This whole argument is fairly silly, since if mta-sts catches on, the
mail providers will all do it for you anyway.  Google provides it for
gmail.com and google.com so their other zillion domains shouldn't be
far behind.

---

From: Tony Finch <[email-masked]>
Date: Tue, 8 Oct 2019 12:34:00 +0100

> example.com      DOTNS ns1.example.com

There are interesting problems with using extra delegation records to
bootstrap DoT:

The DNS protocol has to have special logic for every RRtype that appears
at a delegation, so you would need some kind of signalling to indicate
that this is OK for all the parties involved. (I have not thought about
the details of what would be required...)

You also need to upgrade EPP so that registrars can get the extra records
into the registry database so that the registry can put them in the TLD.
And then wait an indefinite time for the registrars to upgrade their
customer-facing interfaces so that you can tell them about the extra
records.

It's very awkward.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
German Bight, Humber: Southwest 5 to 7. Moderate or rough. Showers. Good.

---

From: Keith Moore <[email-masked]>
Date: Tue, 8 Oct 2019 09:29:44 -0400

On 10/8/19 7:34 AM, Tony Finch wrote:

> Keith Moore<[email-masked]>  wrote:
>
I'm curious about this.   I thought all of the logic required was on the 
server end.
> into the registry database so that the registry can put them in the TLD.

Ah, that makes sense.

But I've been convinced for at least 20 years that the DNS protocol 
needed an upgrade path anyway, and that having new kinds of "NS" records 
was the only good way to do it.   So to me the effort required to add 
support for new delegation records seems like a necessary investment.

> customer-facing interfaces so that you can tell them about the extra

Yes, this is a given.   One of the big problems with the 
registry-registrar model is that registrars get too much latitude about 
their customer interfaces.

Keith

---

From: Tony Finch <[email-masked]>
Date: Tue, 8 Oct 2019 14:59:44 +0100

> I'm curious about this.   I thought all of the logic required was on the

The DOTNS spec has decide if the records are like NS (appear both below
and above the cut) or like DS (above the cut only) so that resolvers are
able to know where to ask for them. For this to make sense from a DNSSEC
point of view the above-the-cut DOTNS records should probably be signed by
the parent zone (like DS) rather than being an unsigned non-authoritative
hint (like NS), so validators have to handle the zone cut correctly when
checking the RRSIG(DOTNS) signer name. There are probably other things
that need careful thought.

> But I've been convinced for at least 20 years that the DNS protocol needed an
> upgrade path anyway, and that having new kinds of "NS" records was the only
> good way to do it.   So to me the effort required to add support for new
> delegation records seems like a necessary investment.

You are right. Sadly the experience of adding DS records has not been at
all successful: there hasn't been enough carrot/stick to implement the
upgrade on a sensible timescale. There would need to be quite a big change
of attitude for it to be worth trying something similar again.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shetland Isles: South or southwest 4 to 6. Rough or very rough, but moderate
in shelter. Rain or showers. Good, occasionally poor.

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Tue, 08 Oct 2019 09:58:22 -0400

On Mon, 07 Oct 2019 15:10:29 -0400, "Stan Kalisch" said:

> That may be, but I do not think, however, that this addresses Viruthagiri's
> assertion about the cost being prohibitive for some in developing countries.

The point is that there's 3 basic cases:

1) You're outsourcing the e-mail to a company. The added cost for the webserver
will probably be close to zero, because if the proposal gets enough traction to matter,
hosting companies will be able to do it at scale, and bundle it for free.

2) You're doing low-volume e-mail in-house. The added resources needed for
the webserver will probably be close to zero, because somebody will write a
"how-to" or even write an open-source program that you enter your domain name
and host name, and it writes the config files for you.

3) You're doing in-house e-mail at a volume that the web server resources matter.
At this point, you're *already* going to be fighting with scaling issues with  your SMTP
system and the web server is the least of your worries....

Yes, in some situations the cost of e-mail for an organization can be prohibitive.
However, this isn't a proposal that doubles the cost of doing it. It's more likely
going to add a half-percent or so - there's probably going to be a half-dozen things
applying more economic pressure.

And it's probably *far* too early in the protocol design process to be saying "oh,
but this *might* be a problem for a very very small percentage of sites" - especially
since we're talking about an *optional* extension.

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Wed, 9 Oct 2019 03:17:41 +0530

> hosting companies will be able to do it at scale, and bundle it for free.

The future you are predicting would look something like this. "Buy our
hosting package and get $99 worth web server + $99 worth SSL certificate
for free for MTA-STS". When these hosting companies offer something for
free, it's "Free" as in "Freebie". Not "Free" as in "Freedom". We are not a
marketing team for these hosting companies. We are here to solve a problem
and we have to do it in the most efficient way.

A problem can be solved in many ways. Let's just say, a patient goes to see
a doctor with a rash on his leg. The doctor chops off patient's leg and
then give him a walking stick. Technically speaking, the doctor solved the
patient's problem. But, is it the right way to solve the patient's problem?
Maybe in 10,000 BC. But in the modern world, it makes sense only if the
rash was caused by a life threatening disease and it is the only way to
solve the problem.

When the doctor do this on a massive scale, he can definitely afford to
offer a free walking stick for each patient. So If you are going to
evaluate his solution based on the walking stick cost, then that's gonna
produce abnormal results. Without the leg, the patient has to depend on the
walking stick forever. That's a huge inconvenience and it is one of the
most notable variable to consider.

In the case of MTA-STS, SMTP has to depend on a web protocol forever and
that's the prima facie reason why MTA-STS is bad. Cost being prohibitive is
one of the secondary reasons. Speaking of cost, you are being subtle here.
"probably be close to zero" is not the same as "zero". We don't have
control over a company's business model and these hosting companies usually
find a way to increase their profits. e.g. Google recently increased their
G-Suite pricing by $1. So even if you put $1 as price tag for each MTA-STS
deployment, the world will be spending millions of dollars once it get
popular. That's not "close to zero". Most people in the world would like to
save their money even if it just a penny.

Bottomline is, MTA-STS should be used as a last resort when there is no
better alternatives possible. And that's just my humble opinion.

-- 
Best Regards,

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 8 Oct 2019 19:03:18 -0400

> On Oct 6, 2019, at 8:10 PM, John R Levine <[email-masked]> wrote:
> 

Small correction.  MTA-STS is defined and works a *small* number of
*very* large mail systems.  There are best I can measure only a few
hundred domains covered by MTA-STS, but they include gmail.com, and
outlook.com (enforce) and yahoo.com (still testing).

By contrast DANE is defined and works for a very large number (~1.3
million) domains that are small to medium mail systems.  These
include comcast.net, web.de, gmx.de, protonmail.ch, and some large
domain hosting providers.

Only some in-house certificate management automation appears to stand
between Google and DANE for SMTP, they already have DNSSEC-signed MX
hosts:

	mx[1-4].smtp.goog.

that are live and listed jointly in the Google MX certificates with
the existing better known names.  Once these have TLSA records, any
of the O(600k) signed domains that presently use Google's various
MX hosts could change their MX RRs to mx[1-4].smtp.goog, and have
DANE for their Google hosted domains.

I would not be surprised to see DANE for Google become available in
the next 12 months, but can only speculate, it could happen sooner,
or not at all...

-- 
	Viktor.

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 9 Oct 2019 04:22:26 -0400

> The point is that there's 3 basic cases:

[ good analysis elided ]

It's the resources outside these that can be a major problem.  In some
environments, "offering another service to the public Internet" requires
formal proposals, discussions, meetings, i's dotted and t's crossed,
auditors placated, security people mollified, and so on.  And while
in this particular case it can be argued "we're making email more secure
by doing this" it still won't be an easy sell to some.

(more generally) Making email more secure/private is goodness.  Doing it
via multiple kludges based on TXT records and hostnames and HTTP and
so on is not.  I'm (painfully) well aware of the obstacles in the way
of doing it cleanly, but doing it this way incurs debt that sooner or
later we'll have to pay.

---rsk

---

From: "John Levine" <[email-masked]>
Date: 9 Oct 2019 11:59:47 -0400

>of doing it cleanly, but doing it this way incurs debt that sooner or

Mta-sts was hashed out at a dinner at the Buenos Aires IETF meeting.
Everyone knew what the tradeoffs were, and that the web server with a
fixed name is a kludge.  What it basically boiled down to was that
if they had to choose between needing a web server and needing DNSSEC
before they could deploy, they picked the web server.

I do both mta-sts and TLSA and I can assure you that the practical
obstacles to getting DNSSEC deployed remain painful.  I provide DNS
for a lot of domains where I am not the registrant or registrar, and
the only way to get the DS record installed is to log in with the
registrant's password which for obvious I don't want to do.  There
are also still some TLDs that don't do DNSSEC at all.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Wed, 09 Oct 2019 12:54:57 -0400

> of doing it cleanly, but doing it this way incurs debt that sooner or

+1

My concern is the increasing overhead and operational cost as well. 
Add HTTPS requirements with newer heighten PCI/SSL requirements like 
HSTS, and it can get really complicated with HTTPS client/server 
compatibility issues.

-- 
HLS

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 9 Oct 2019 21:31:20 -0400

> On Oct 9, 2019, at 11:59 AM, John Levine <[email-masked]> wrote:
> 
> There are also still some TLDs that don't do DNSSEC at all.

For anyone who's keeping score, ... current list of unsigned
TLDs below:

117 (out of 248) ISO 2 letter ccTLDs:

  ae ai al ao aq as ba bb bd bf bh bi bj bn bo bs bv cd cf cg ci ck
  cm cu cv cw cy dj dm do ec eg er et fj fk fm ga gb ge gf gg gh gm
  gp gq gt gu hm ht im iq ir je jm jo kh km kn kp kz ls ly mg mh mk
  ml mm mo mp mq mr ms mt mu mv mw mz ne ng ni np nr om pa pf pg ph
  pk pn ps py qa rw sd sl sm so sr st sv sy sz tc td tg tj tk to tr
  uz va vg vi ye zm zw

1 (out of 1209) gTLDs:

  aero

21 (out of 69) IDN ccTLDs:

  xn--mgbaam7a8h       AE UAE امارات
  xn--54b7fta0cc       BD Bangladesh বাংলা
  xn--90ais            BY Belarus бел
  xn--lgbbat1ad8j      DZ Algeria الجزائر
  xn--node             GE Georgia გე
  xn--mgbtx2b          IQ Iraq عراق
  xn--mgba3a4f16a      IR Iran ایران
  xn--mgbayh7gpa       JO Jordan الارد
  xn--80ao21a          KZ Kazakhstan қаз
  xn--xkc2al3hye2a     LK Sri Lanka இலங்கை
  xn--fzc2c9e2c        LK Sri Lanka ලංකා
  xn--mgbc0a9azcg      MA Morocco المغرب
  xn--d1alf            MK North Macedonia мкд
  xn--mix891f          MO Macao 澳門
  xn--mgbah1a3hjkrd    MR Mauritania موريتانيا
  xn--mgb9awbf         OM Oman عمان
  xn--ygbi2ammx        PS Palestine فلسطين
  xn--wgbl6a           QA Qatar قطر
  xn--mgbpl2fh         SD Sudan سودان
  xn--ogbpf8fl         SY Syria سورية
  xn--j1amh            UA Ukraine укр

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 9 Oct 2019 21:55:15 -0400

In article <[email-masked]> you write:
>TLDs below: ...

There are TLDs that are signed but don't let you install DS records.
I have a .am name but even though the TLD is signed, there is not as
far as I can tell any way to get my 2LD signed.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 Oct 2019 00:05:53 -0400

> On Oct 9, 2019, at 9:55 PM, John Levine <[email-masked]> wrote:
> 

Have you tried recently?  I see signed delegations, for example, for:

  freebsd.am
  jabber.am
  john.am
  name.am
  ... 18 in total ...

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 10 Oct 2019 12:09:03 -0400

>Have you tried recently?  I see signed delegations, for example, for:

Yes, I opened a ticket at registrar and they sent a clueless response
saying that the DNS provider does DNSSEC.

I wrote back and told them to ask the registry how the registrar
provides the DS record to like the TLD DNSSEC to the 2LD.  We'll see.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 10 Oct 2019 16:36:04 -0400

In article <[email-masked]> you write:
>>> far as I can tell any way to get my 2LD signed. ...

>provides the DS record to like the TLD DNSSEC to the 2LD.  We'll see.

Oh, whoops, thay said, and sp.am is now signed.  But with this much
effort, no wonder most other 2LDs in .am are not.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 11 Oct 2019 00:32:47 -0400

> On Oct 10, 2019, at 4:36 PM, John Levine <[email-masked]> wrote:
> 

Yes, one of they key barriers to DNSSEC adoption is lack of a uniform
interface between registrant and registrar for creation and maintenance
of DS RRsets.

CDS support at registries is essential to removing this roadblock to DNSSEC
adoption, by getting the registrar out of the critical path.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 11 Oct 2019 12:08:01 -0400

>interface between registrant and registrar for creation and maintenance

Not just registrant, but DNS operator.  As I may have said once or
twice, I have about 100 zones where I run the DNS for someone else,
and I am not going to pretend to be my registrants to install the DS
records.

>adoption, by getting the registrar out of the critical path.

Unless I missed something, CDS currently only lets you update DS records,
not install them initially.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 11 Oct 2019 13:20:20 -0400

> On Oct 11, 2019, at 12:08 PM, John Levine <[email-masked]> wrote:
> 

At least two registries supports bootstrapping DNSSEC via CDS.

	https://www.nic.ch/faqs/dnssec/cds/
	https://ripe75.ripe.net/presentations/123-CDNSKEY-FRED-KNOT-RIPE75.pdf

Further links:

	https://meetings.icann.org/en/dublin54/schedule/wed-dnssec/presentation-dnssec-bootstrapping-21oct15-en.pdf
	https://github.com/CIRALabs/DSAP
	https://blog.dnsimple.com/2019/02/cds_cdnskey/

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 11 Oct 2019 14:44:43 -0400

>At least two registries supports bootstrapping DNSSEC via CDS.

I suppose I can put in CDS records and see what happens.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 11 Oct 2019 17:25:05 -0400

> On Oct 11, 2019, at 2:44 PM, John Levine <[email-masked]> wrote:
> 

Please share any unexpected positive results.  I've only heard
about CDS bootstrapping support in the context of .CZ, .CH/.LI
and perhaps .CA.  I hope you're able to uncover others and/or
confirm the above.

-- 
	Viktor.

---

From: Tony Finch <[email-masked]>
Date: Mon, 14 Oct 2019 12:02:38 +0100

> not install them initially.

RFC 7344 did not include bootstrapping, but that was added by RFC 8078.
Sadly it's more like a set of hints rather than an actual protocol...

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rattray Head to Berwick upon Tweed: South or southeast, backing east or
northeast, then backing north later, 2 to 4. Slight. Occasional rain later.
Good, occasionally moderate in south.

---

From: "John R Levine" <[email-masked]>
Date: 14 Oct 2019 10:22:09 -0400

> Sadly it's more like a set of hints rather than an actual protocol...

It's just hand waving.  The guys who wrote it know that, but the problem 
is that there was no consensus on how to bootstrap.  It's a hard problem 
since it's sort of inherent that there's nothing other than a DNSSEC 
signature that reliably authenticates a DNSSEC record.

Regards,

---

From: Tony Finch <[email-masked]>
Date: Tue, 15 Oct 2019 12:33:57 +0100

John R Levine <[email-masked]> wrote:
> It's just hand waving.  The guys who wrote it know that, but the problem is
> that there was no consensus on how to bootstrap.  It's a hard problem since
> it's sort of inherent that there's nothing other than a DNSSEC signature that
> reliably authenticates a DNSSEC record.

I think if we get more registries copying .cz and/or .ch then some
consensus may emerge but there doesn't seem to be much movement in this
area...

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Mull of Galloway to Mull of Kintyre including the Firth of Clyde and North
Channel: Southeasterly 4 or 5, occasionally 3 at first in Firth of Clyde,
increasing 6 or 7, veering westerly 4 or 5, backing southwesterly 3 or 4
later. Smooth or slight, becoming slight or moderate. Showers, then occasional
rain, becoming fair later. Good, occasionally poor.

---

From: Hector Santos <[email-masked]>
Date: Tue, 15 Oct 2019 12:52:18 -0400

I wish I understood more of this discussion and "basic problem," if 
any, but in years past, we use to share common "Network" files using 
dialup, ftp, web, etc.   We sort of do it now with the CA-BUNDLE.TXT 
file for the Intermediate CAs certs.  When I build new OpenSSL images, 
the wcSSL package distribution includes a new ca-bundle.txt file with 
new CA certs merged.  The main bundle is from:

https://raw.githubusercontent.com/bagder/ca-bundle/master/ca-bundle.crt

In the last update, I merged a bunch of them:

##  07/31/18 01:56 pm
##  - Using MergeCACerts.cmd
##  - merge newbundle\ca-bundle-20180626.txt 
https://raw.githubusercontent.com/bagder/ca-bundle/master/ca-bundle.crt
##  - merge newbundle\AddTrustExternalCARoot.pem   Comodo
##  - merge newbundle\COMODORSAAddTrustCA.pem Comodo
##  - merge 
newbundle\COMODORSAOrganizationValidationSecureServerCA.pem Comodo
##  - merge newbundle\chain.pem  Let's Encrypt
##  - merge newbundle\gd_bundle-g2-g1.crt  GoDaddy
##  - merge newbundle\gd_bundle.crt GoDaddy

But it just dawn on me, should a site like the above domain be trusted 
as a TTP (Trusted Third Party) CA?  The bundle can contain TTP 
"posers."   For that matter, why should the user trust any CA anyway?

--
HLS

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 15 Oct 2019 21:10:47 +0200

On Tuesday 15 October 2019 18:52:18 CEST, Hector Santos wrote:
> I wish I understood more of this discussion and "basic 
> problem," if any,

It's this: if someone were to tell the .com registry that starting 
immediately, they wish to sign domain hsantos.com and will the .com 
registry please include the necessary RRs in .com, how would the .com 
registry know whether to trust that someone?

Once the domain is signed and the records are in .com, there's a fine 
mechanism that anyone can use to check whether that someone actually 
controls hsantos.com. But what about the initial inclusion of the 
signature-related records in the .com zone?

There are ways, sometimes at least. For example, if it's done when the 
domain is initially registered, then it's clear that the registrant 
actually is the registrant. But initiating trust is a difficult problem if 
you want to solve it generally.

Arnt

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Tue, 15 Oct 2019 16:23:18 -0400

> "posers."   For that matter, why should the user trust any CA anyway?

If there were a small number of top-level CAs of irreproachable reputation,
it wold be one thing. But when the bar is low enough that there's 600+
organizations that qualify....

---

From: Hector Santos <[email-masked]>
Date: Tue, 15 Oct 2019 21:36:59 -0400

> organizations that qualify....

The old centralization vs decentralization dilemma.

The technical security aspect of encryption is no longer good enough 
-- certs now have to be CA-signed now.   What concerns me is when 
self-signed certs will be technically degraded (for many reasons, 
including DPI overhead).  I am seeing it at a localized (HTTPS) level. 
I predict this is going to be a big problem.  For SMTP, we don't have 
the same Browser/CA market control.

Thanks Valdis and Arnt.

P.S.  What is the end result of all this?

-- 
HLS

---

From: Keith Moore <[email-masked]>
Date: Tue, 15 Oct 2019 21:56:40 -0400

On 10/15/19 9:36 PM, Hector Santos wrote:

> -- certs now have to be CA-signed now.

Certs that weren't signed by a trusted party were never worth anything 
anyway, unless maybe you manually pinned them.

Keith

---

From: "John Levine" <[email-masked]>
Date: 15 Oct 2019 22:16:53 -0400

>anyway, unless maybe you manually pinned them.

We were talking about bootstrapping DNSSEC.  Certs?  What are those?

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Oct 2019 13:36:28 +1100

On 16 Oct 2019, at 6:10 am, Arnt Gulbrandsen <[email-masked]> wrote:
>> I wish I understood more of this discussion and "basic problem," if any,
> 
> It's this: if someone were to tell the .com registry that starting immediately, they wish to sign domain hsantos.com and will the .com registry please include the necessary RRs in .com, how would the .com registry know whether to trust that someone?
> 
> Once the domain is signed and the records are in .com, there's a fine mechanism that anyone can use to check whether that someone actually controls hsantos.com. But what about the initial inclusion of the signature-related records in the .com zone?
> 
> There are ways, sometimes at least. For example, if it's done when the domain is initially registered, then it's clear that the registrant actually is the registrant. But initiating trust is a difficult problem if you want to solve it generally.

Well when the delegation was initially registered credential where exchanged
even if that was a user name / password pair.  This allowed NS records and
glue address records to be updated securely.  Updating/adding DS records is no
different.  You use the existing mechanisms, initially this was talking to the
registry directly.  These days it is intermediated through a registrar.

Or did you think anyone could change NS records for hsantos.com?

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Oct 2019 23:20:34 -0400

> On Oct 15, 2019, at 10:36 PM, Mark Andrews <[email-masked]> wrote:
> 

Yes, but as you're well aware, with DNSSEC users need a standard
interface that enables automation of KSK/DS updates, and the extra
hop through the registrar is rather a major obstacle.  Also,
in many cases the DNS zone operator needs to be empowered to
do key management, without necessarily having full control of
the zone for transfers, ...

Perhaps it should be possible for the user to obtain from a token
that authorizes a key pair for direct access to the registry for
(purposes of DS RR updates) by the holder of the keypair.  The
token (and associated key) might then be delegated to the DNS
operator.

That token is presently a signed CDS/CDS0 record, which handles
everything but initial enrollment (bootstrapping), for which
.CZ, .CH, et. al. are exploring ToFU approaches.

-- 
	Viktor.

---

From: Hector Santos <[email-masked]>
Date: Tue, 15 Oct 2019 23:30:38 -0400

> anyway, unless maybe you manually pinned them.

Yes, 100% +1 but traditionally, it is a known target, i.e. well known 
users using a well-known trusted site. As long as the common name 
matches, it is secured. No?
What I am seeing for the first time ever in HTTP history, HTTP comm 
I/O is ok, HTTPS is degraded by the ISP if self-signed. Explain that. 
  They can't. Too classified. :-(

-- 
HLS

---

From: Keith Moore <[email-masked]>
Date: Wed, 16 Oct 2019 03:03:51 -0400

On 10/15/19 11:30 PM, Hector Santos wrote:

> I/O is ok, HTTPS is degraded by the ISP if self-signed.

How do you know that it's the ISP that's doing the degrading?

Keith

---

From: Tony Finch <[email-masked]>
Date: Wed, 16 Oct 2019 14:15:26 +0100

> Or did you think anyone could change NS records for hsantos.com?

Well, not *anyone*, but CSYNC support would also be nice :-)

(The "* Note:" paragraph https://tools.ietf.org/html/rfc7477#page-7
makes me lolsob a bit wrt cam.ac.uk's nameserver setup!)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
promote human rights and open government

---

From: Hector Santos <[email-masked]>
Date: Wed, 16 Oct 2019 13:59:19 -0400

> How do you know that it's the ISP that's doing the degrading?

I provided detailed info off-list, but you're right. I don't know for 
sure, but the ISP escalation engineer has acknowledged the HTTPS 
degradation problem is occurring with WAN comm I/O. Not LAN comm I/O, 
and only HTTPS. HTTP is fine.

I am trying to get a handle on it. Technically, at this point, it 
appears when CA-signed certs are used or a HTTP 1.1 persistent socket 
connection is in play, this "mysterious," passive network security 
proxy degradation problem disappears.  It appears to be new, isolated 
and experimental with my small biz as a guinea pig.

If SMTP operations evolve to where similar enforcement with CA-signed 
certs occurs, we probably won't see much of a degradation to notice 
anything since for the most part, it is a single-shot transfer of a 
payload.  But with HTTPS, a page can have 10s, 100s of requests to 
complete the page display.

-- 
HLS