Subject: Re: [Uta] Dealing with STARTTLS Stripping

From: Aaron Zauner <[email-masked]>
Date: Thu, 03 Dec 2015 18:51:23 +0100

*Caught* Just dusted this of during a discussion.

I wanted to point out:
http://conferences2.sigcomm.org/imc/2015/papers/p27.pdf

Due to be a full Talk at 32c3 as well.

I don't care what we do - but we should at least discuss this properly.
I haven't seen a sound proposal that would mitigate active attacks yet
and really dislike anything DNSSEC based (YMMV, some people do also
believe in IPv6 security).

Aaron

---

From: "Brotman, Alexander" <[email-masked]>
Date: Fri, 4 Dec 2015 15:55:15 +0000

Aaron,

There's a group of folks from M3AAWG that are working toward a sort of mechanism for SMTP, roughly using some ideas relating to HSTS and/or certificate transparency.  The idea being that you would specify a published policy where a sender can see that you expect that sessions will be encrypted, and report TLS failures to the receiving system (without TLS).

--
Alex Brotman
Engineer, Anti-Abuse
Comcast
x5364

-----Original Message-----
From: Uta [mailto:[email-masked]] On Behalf Of Aaron Zauner
Sent: Thursday, December 03, 2015 12:51 PM
To: [email-masked]
Subject: Re: [Uta] Dealing with STARTTLS Stripping

I wanted to point out:

I don't care what we do - but we should at least discuss this properly.
I haven't seen a sound proposal that would mitigate active attacks yet and really dislike anything DNSSEC based (YMMV, some people do also believe in IPv6 security).

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 04 Dec 2015 23:56:21 +0100

> There's a group of folks from M3AAWG that are working toward a sort of mechanism for SMTP, roughly using some ideas relating to HSTS and/or certificate transparency.  The idea being that you would…

I think you're talking about smtp-sts.

And I also think I've broken your proposal in this GitHub issue:
https://github.com/mrisher/smtp-sts/issues/1

I'm very appreciative to any efforts into that direction but they need
to be scalable and need to be deployable to all of the 4mio MXs on the
Internet that aren't a major mail hosting provider. Please do not go
with DNS. I'm not saying that my proposal is perfect. Far from it but if
we collaborate something useful for everyone (even mail exchanges with a
single domain) could be worked out.

Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 5 Dec 2015 20:27:54 +0000

On Fri, Dec 04, 2015 at 11:56:21PM +0100, Aaron Zauner wrote:

> > Aaron,
> > 
> > There's a group of folks from M3AAWG that are working toward a sort of
> > mechanism for SMTP, roughly using some ideas relating to HSTS and/or
> > certificate transparency.  The idea being that you would specify a published
> > policy where a sender can see that you expect that sessions will be
> > encrypted, and report TLS failures to the receiving system (without TLS).
> 

Yes, that's the document.  It still needs some work, but it can be
a stop-gap for the larger providers while they gear up to implement
DNSSEC (a few years work).

> https://github.com/mrisher/smtp-sts/issues/1

No.  Neither DEEP nor TACK can protect MTA-to-MTA SMTP.  The reason
is MX indirection.  DEEP and TACK pin server properties, not domain
properties.  The MITM will just forge the MX RRset and bypass DEEP
and TACK.  In any case, there are domains to which I send email
very infrequently, but still want the transport to be secure, none
of DEEP, TACK or STS address that.

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Sat, 05 Dec 2015 23:14:52 +0100

Hi Viktor,

> DNSSEC (a few years work).

For large hosting providers this proposal makes sense, as I've noted.
For the run-of-the-mill mail-server it won't really help that much in my
opinion. See below.

That said I've also noted my issues with DNSSEC in my GitHub issue.

> of DEEP, TACK or STS address that.

I'm not saying that TACK is the only and ultimate way to go. It served
as an example in this case. The major problem I see with DNS is that a
lot of small mail-servers do not get a lot of attention, some of their
operators might not even have direct DNS access (think semi-hosted setup
where you have to either go through a web interface of your provider or
actually write an e-mail. Another case is where the Postmaster has no
real influence on DNS record because of company/university/whatever
bureaucracy). I know you heavily support DANE and I do like DANE in
general but see major problems in DNSSEC still (not only deployment).

Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 5 Dec 2015 19:06:01 -0500

> On Dec 5, 2015, at 5:14 PM, Aaron Zauner <[email-masked]> wrote:
> 
> actually write an e-mail.

Well somebody publishes MX and/or A records for the domain so it can
get mail.

> Another case is where the Postmaster has no

MTA-to-MTA SMTP (relay) establishes connections to wherever the MX records
point.  The MX records are in DNS.  Therefore, if active attacks are in
scope, and DNS is not protected from active attack, you cannot protect
of MTA-to-MTA SMTP from active attack.  None of the proposals you suggest
both scale and work if DNS is subject to MITM.

If you have an architecture that somehow avoids critical reliance on DNS
security, and works even for infrequent or first-time communication, you
need to explain how it does in some detail.  I've not seen anything that
matches that description.

Similar observations can be made for MUA to MSA in the RFC 6186 scenario
(SRV records for locating the submission, imap and/or pop servers).

As for postmasters v.s provider hosted domains, I might note that udmedia.de
have published TLSA records for the MX hosts of ~30,000 (perhaps more now)
domains, without any need for the domain owner to take explicit action for
that to happen.  There also a few thousand such domains hosted by each of
nederhost.net and transip.nl.  The provider case is actually the easy one,
if the provider is willing to take the appropriate steps.  If not, switch
to a better provider.

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Sun, 06 Dec 2015 04:24:53 +0100

Hi,

> Well somebody publishes MX and/or A records for the domain so it can

Sure, there's no way around *this* step.

> both scale and work if DNS is subject to MITM.

Yes but verification will fail if you MITM DNS and redirect to an
previously unpinned server.

> matches that description.

This is certainly true as I haven't worked out (or even started) with an
appropriate I-D or anything really besides the very informal e-mail with
which this thread started out. And this is the first feedback I've
gotten since. Due to research work I haven't found time to write
anything up yet that goes beyond this. By IETF Note Well this still
serves as a contribution to IETF discourse.

The smtp-sts I-D on GitHub is still lacking a lot of details, so I can
just make assumptions. Currently, with the policy is authenticated via
WebPKI instead of TLSA you'll need complete out-of-band verification for
MTA to MTA transactions. I've come up with the same idea in January and
after some discussion with other security people quickly abandoned this
idea and never wrote about it to IETF. A Postmaster operating the MX
needs to be in control of the issued WebPKI certificate (which means:
ideally the certificate supports Certificate Transparency and HPKP
headers are set on the Web-server). This might be impractical for many
operators:

Currently more than 60% of SMTP MTAs do _not_ have signed certificates,
far less even provide valid CN or SAN X.509 information. TACK does not
require certificates to be CA-signed, this is completely optional. TACK
also makes revocation and key-rollover a bit easier than this proposal.
TACK also makes life-cycle management and clustered set-ups a bit easier
as multiple MXs could be pinned to the same TSK.

Again; that might work fine for the companies the authors of smtp-sts
work for and their large hosting infrastructures, it will not work for
the common SMTP instance somewhere below a desk in an office. I don't
see that this proposal would be widely deployed by mail operators.

The proposal also means significant change to already deployed codebases
for mail transfer. And quite a bit of extra effort on the operator side
as I've already noted. We need something that'll do with `sudo apt-get
update`, ideally. Otherwise I fear we won't see much deployment.

> if the provider is willing to take the appropriate steps.  If not, switch

Thanks for the numbers.

Switching providers for operators might not as easy as you think it is
due to contractual agreements or pre-existing dependencies on other
support infrastructure (for example DNS or even the smtp-sts supporting
WebPKI infrastructure which might not be hosted on the same machine).

I'll think more about this - need to get some sleep.

Thanks for you feedback,
Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 6 Dec 2015 03:48:00 +0000

> previously unpinned server.

I don't think domain-level pinning, rather than per-server pinning
is workable.  Pins expire, domains change hands, and MTAs unlike
MUAs and browsers don't have users to "click OK" when stuff breaks.

> A Postmaster operating the MX

With STS (which I am not currently endorsing as a universal approach
beyond the small club of the largest providers behind this design)
the destination domain owner publishes the policy which essentially
pins the MX RRset and specifies authenticaiton of same.  The
webserver that authenticates the policy is at a well-known URI
associated with the destination domain.  The MX operator just has
to maintain valid WebPKI certificates from some widely trusted CA,
that are associated with the MX hostname.  I don't see why CT
support or lack thereof is pertinent here.

> far less even provide valid CN or SAN X.509 information.

Because why pay for bits everyone is going to ignore anyway.  The
sysadmins are behaving rationally.
 
> TACK does not

I'd considered TACK for SMTP, but gave up once it became clear that
TACK (per-server key pinning) is of no use given MX indirection.

> see that this proposal would be widely deployed by mail operators.

FWIW, I don't think that STS is universally applicable either, ...
That said I'm going to contribute some cycles and text to making
it as good as it can be, and then time will tell.  Worst case it
will help the large providers secure their inter-organizational
connections and protect a large fraction of mail by volume, rather
than domain diversity.

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Sun, 06 Dec 2015 17:39:33 +0100

Hi,

> MUAs and browsers don't have users to "click OK" when stuff breaks.

How would you imagine per-server pinning with workable key-rollover?

I too see problems with expired pins -- see below.

> support or lack thereof is pertinent here.

It's not but would be nice to have, no?

> sysadmins are behaving rationally.

Sure. But then again they need signed certs for the WebPKI reporting and
authentication anyway as far as I understand the current proposal (it's
not submitted to IETF so we're discussing something that the authors
might not even envision).

> TACK (per-server key pinning) is of no use given MX indirection.

TACK has various problems there, and it's a bit dated by now given
change in some parts of the WebPKI infrastructure and new protocol
proposals within IETF. We could pick it up, dust it off and find a
proper way to use it for e-mail though, this is my idea. There's no
reason in verbatim employing TACK as currently documented.

> connections and protect a large fraction of mail by volume, rather

I see it makes a lot of sense for large hosting providers, and have
noted so repeatedly. The problem is: they're already doing fine with
security deployment and some of them might already have some form of
"pinning" (say Google knows Yahoo's server information and the other way
around - not sure if that's really the case but I'd do it this way on
that scale even without a proper protocol given the Snowden
disclosures). If we end up with a protocol that's only deployable for
large providers we don't get added security for the small self-hosted
MXs on the Internet - and this is my concern. We can't just tell all of
them to use GMail as an MX.

Thanks for your feedback,
Aaron

---

From: "Brotman, Alexander" <[email-masked]>
Date: Wed, 9 Dec 2015 13:54:13 +0000

Aaron, 

Yes, that's what I was referring to, and I now see your comments, along with Dan's.  I think we'd welcome feedback from all interested parties, even if they don't believe it to be a universal solution.  Eventually, we'll have a mailing list hosted somewhere so that others can easily follow along.

--
Alex Brotman
Engineer, Anti-Abuse
Comcast
x5364

-----Original Message-----
From: Aaron Zauner [mailto:[email-masked]] 
Sent: Friday, December 04, 2015 5:56 PM
To: Brotman, Alexander <[email-masked]>
Cc: [email-masked]
Subject: Re: [Uta] Dealing with STARTTLS Stripping

I'm very appreciative to any efforts into that direction but they need to be scalable and need to be deployable to all of the 4mio MXs on the Internet that aren't a major mail hosting provider. Please do not go with DNS. I'm not saying that my proposal is perfect. Far from it but if we collaborate something useful for everyone (even mail exchanges with a single domain) could be worked out.

Aaron

---

From: Michael Ströder <[email-masked]>
Date: Thu, 10 Dec 2015 16:41:15 +0100

> general but see major problems in DNSSEC still (not only deployment).

I concur that DNS (DNSSEC and TLSA) is the main obstacle for DANE.

Ciao, Michael.