From bart at knubben.org  Thu May 18 09:23:22 2017
From: bart at knubben.org (Bart Knubben)
Date: Thu, 18 May 2017 09:23:22 +0200
Subject: Test tool havedane.net and NCSC-NL factsheet on DANE
Message-ID: <CANgq3t759ymCMr5NeU7BRA7g7khnexAsGDXLVZNU=G6wv_t+rQ@mail.gmail.com>

1. Check this new tool for testing if your mail server checks DANE
when sending email: https://havedane.net

2. Recently the Dutch NCSC published a factsheet "Secure the
connections of mail servers" with regard to DANE and STARTTLS. See:
https://www.ncsc.nl/english/current-topics/factsheets/factsheet-secure-the-connections-of-mail-servers.html

-- 
Best regards,
Bart Knubben

From ietf-dane at dukhovni.org  Thu May 18 16:51:33 2017
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Thu, 18 May 2017 10:51:33 -0400
Subject: Test tool havedane.net and NCSC-NL factsheet on DANE
In-Reply-To: <CANgq3t759ymCMr5NeU7BRA7g7khnexAsGDXLVZNU=G6wv_t+rQ@mail.gmail.com>
References: <CANgq3t759ymCMr5NeU7BRA7g7khnexAsGDXLVZNU=G6wv_t+rQ@mail.gmail.com>
Message-ID: <BF3646F6-EE46-4B9C-B184-93DE58C26DB4@dukhovni.org>


> On May 18, 2017, at 3:23 AM, Bart Knubben <bart at knubben.org> wrote:
> 
> 1. Check this new tool for testing if your mail server checks DANE
> when sending email: https://havedane.net

It is a step in the right direction, though testing should ultimately
be much more comprehensive.

	* Test that "expired" certificates are accepted with DANE-EE(3)

	* Test that matching hostnames are not required with DANE-EE(3)

	* Test multiple DANE-EE(3) SPKI(1) SHA2-256(1) records with
	  just one matching the chain.

	* Probe for digest agility support, test a working SHA2-512(2)
	  a non-working SHA2-256(1) and vice versa.

	* Test DANE-TA(2) support with TA certificate in the server chain

	* Test DANE-TA(2) with wildcard leaf certificate.

	* Test DANE-TA(2) with expired leaf certificates, or non-matching
	  DNS-ID.

	* Test optional DANE-TA(2) SPKI(1) Full(0) support with the trust
	  anchor public key in DNS and the full certificate NOT provided
          in the chain (Postfix supports this, other MTAs might not.  Per
	  RFC7671 support this corner case is optional, and servers MUST
	  include the trust anchor CA certificate in their chain.

	* Test support for a combination of a DANE-TA(2) and a DANE-EE(3)
-- 
	Viktor.
	  (both cases).

	* Test TLSA record lookup failures (broken RRsig, broken denial of
	  existence, ...)

	* Test DNSSEC-signed domains with MX hostnames in an unsigned zone.
	  Their TLSA records should not be looked up (delegate "_tcp" to
          non-responding and perhaps query-logging servers, sender should
	  not be delayed by trying to look these up).

	...

If you want to check that your Postfix is doing DANE minimally correctly
per this site, just try:

$ myemail=...
$ sendmail -bv -f $myemail probe-rcpt at wrong.havedane.net
$ sendmail -bv -f $myemail probe-rcpt at do.havedane.net
$ sendmail -bv -f $myemail probe-rcpt at dont.havedane.net

Then check your logs.  You should see something along the lines of:

May 18 10:10:59 amnesiac postfix/pickup[60085]: B48AC3904F: uid=1001 from=<...>
May 18 10:10:59 amnesiac postfix/cleanup[60313]: B48AC3904F: message-id=<20170518141059.B48AC3904F at amnesiac.imrryr.org>
May 18 10:10:59 amnesiac postfix/qmgr[17091]: B48AC3904F: from=<...>, size=316, nrcpt=1 (queue active)
May 18 10:11:00 amnesiac postfix/smtp[60315]: certificate verification failed for wrong.havedane.net[5.79.70.105]:25: untrusted issuer /C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/OU=MyOrganizationalUnit/CN=Fort-Funston CA/name=EasyRSA/emailAddress=me at myhost.mydomain
May 18 10:11:00 amnesiac postfix/smtp[60315]: Untrusted TLS connection established to wrong.havedane.net[5.79.70.105]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
May 18 10:11:00 amnesiac postfix/smtp[60315]: B48AC3904F: to=<probe-rcpt at wrong.havedane.net>, relay=wrong.havedane.net[5.79.70.105]:25, delay=1.2, delays=0.03/0.01/1.2/0, dsn=4.7.5, status=undeliverable (Server certificate not trusted)
May 18 10:11:01 amnesiac postfix/bounce[60328]: B48AC3904F: sender delivery status notification: 0CA8939052
May 18 10:11:01 amnesiac postfix/qmgr[17091]: B48AC3904F: removed

May 18 10:11:18 amnesiac postfix/pickup[60085]: D1FFC39054: uid=1001 from=<...>
May 18 10:11:18 amnesiac postfix/cleanup[60313]: D1FFC39054: message-id=<20170518141118.D1FFC39054 at amnesiac.imrryr.org>
May 18 10:11:18 amnesiac postfix/qmgr[17091]: D1FFC39054: from=<...>, size=313, nrcpt=1 (queue active)
May 18 10:11:19 amnesiac postfix/smtp[60315]: Verified TLS connection established to do.havedane.net[5.79.70.105]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
May 18 10:11:19 amnesiac postfix/smtp[60315]: D1FFC39054: to=<47e517f26634fd03 at do.havedane.net>, relay=do.havedane.net[5.79.70.105]:25, delay=1, delays=0/0/0.93/0.1, dsn=2.1.5, status=deliverable (250 2.1.5 Ok)
May 18 10:11:19 amnesiac postfix/bounce[60328]: D1FFC39054: sender delivery status notification: F024239056
May 18 10:11:19 amnesiac postfix/qmgr[17091]: D1FFC39054: removed

May 18 10:11:36 amnesiac postfix/pickup[60085]: 8385E39058: uid=1001 from=<...>
May 18 10:11:36 amnesiac postfix/cleanup[60313]: 8385E39058: message-id=<20170518141136.8385E39058 at amnesiac.imrryr.org>
May 18 10:11:36 amnesiac postfix/qmgr[17091]: 8385E39058: from=<...>, size=315, nrcpt=1 (queue active)
May 18 10:11:37 amnesiac postfix/smtp[60315]: Anonymous TLS connection established to dont.havedane.net[5.79.70.105]:25: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
May 18 10:11:37 amnesiac postfix/smtp[60315]: 8385E39058: to=<47e517f26634fd03 at dont.havedane.net>, relay=dont.havedane.net[5.79.70.105]:25, delay=1, delays=0/0/0.91/0.09, dsn=2.1.5, status=deliverable (250 2.1.5 Ok)
May 18 10:11:37 amnesiac postfix/bounce[60328]: 8385E39058: sender delivery status notification: 99CC23905A
May 18 10:11:37 amnesiac postfix/qmgr[17091]: 8385E39058: removed

-- 
	Viktor.


From dane-users-phil at spodhuis.org  Fri May 19 00:18:03 2017
From: dane-users-phil at spodhuis.org (Phil Pennock)
Date: Thu, 18 May 2017 22:18:03 +0000
Subject: Test tool havedane.net and NCSC-NL factsheet on DANE
In-Reply-To: <BF3646F6-EE46-4B9C-B184-93DE58C26DB4@dukhovni.org>
References: <CANgq3t759ymCMr5NeU7BRA7g7khnexAsGDXLVZNU=G6wv_t+rQ@mail.gmail.com>
 <BF3646F6-EE46-4B9C-B184-93DE58C26DB4@dukhovni.org>
Message-ID: <20170518221803.GA91778@tower.spodhuis.org>

On 2017-05-18 at 10:51 -0400, Viktor Dukhovni wrote:
> If you want to check that your Postfix is doing DANE minimally correctly
> per this site, just try:
> 
> $ myemail=...
> $ sendmail -bv -f $myemail probe-rcpt at wrong.havedane.net
> $ sendmail -bv -f $myemail probe-rcpt at do.havedane.net
> $ sendmail -bv -f $myemail probe-rcpt at dont.havedane.net
> 
> Then check your logs.  You should see something along the lines of:

I just sent one email to all three addresses using my MUA.  Seems
easier. ;)

Exim passes; `exim -Mvl` on the message left on the queue because of
`wrong.havedane.net` yields:

2017-05-18 22:08:49 Received from [censored] H=(tower.spodhuis.org) [censored]:29796 I=[censored]:587 P=esmtpa A=auth_gssapi:[censored] S=613 id=20170518220848.GA91791 at tower.spodhuis.org
2017-05-18 22:08:49 dc6f134be71d9a96 at do.havedane.net: remote_dksign transport succeeded
2017-05-18 22:08:49 dc6f134be71d9a96 at dont.havedane.net: remote_dksign transport succeeded
2017-05-18 22:08:50 dc6f134be71d9a96 at wrong.havedane.net R=outbound_signed T=remote_dksign defer (-37) H=wrong.havedane.net [5.79.70.105]:25: failure while setting up TLS session

The per-message logs are not as helpful to why TLS verification failed,
but the mainlog has more details (if configured appropriately with
log_selector).

The `DS` field flags DNSSEC secure results, the `CV=dane` is
Certificate Verification.

-----------------------------8< mainlog >8------------------------------
2017-05-18 22:08:49 [91803] 1dBTbE-000Nsg-Vq => dc6f134be71d9a96 at do.havedane.net F=<...> P=<...> R=outbound_signed T=remote_dksign H=do.havedane.net DS [2001:1af8:4700:a118:90::7c0]:25 I=[2a02:898:31:0:48:4558:736d:7470]:29798 X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=dane DN="/C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/OU=MyOrganizationalUnit/CN=do.havedane.net/name=EasyRSA/emailAddress=me at myhost.mydomain" C="250 2.0.0 Ok: queued as CF3D2C0CF4" QT=1s DT=0s

2017-05-18 22:08:49 [91803] 1dBTbE-000Nsg-Vq => dc6f134be71d9a96 at dont.havedane.net F=<...> P=<...> R=outbound_signed T=remote_dksign H=dont.havedane.net DS [2001:1af8:4700:a118:90::7c0]:25 I=[2a02:898:31:0:48:4558:736d:7470]:29797 X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no DN="/C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/OU=MyOrganizationalUnit/CN=do.havedane.net/name=EasyRSA/emailAddress=me at myhost.mydomain" C="250 2.0.0 Ok: queued as D82F2C0CF5" QT=1s DT=0s

2017-05-18 22:08:49 [91807] 1dBTbE-000Nsg-Vq H=wrong.havedane.net [2001:1af8:4700:a118:90::7c0] TLS error on connection (SSL_connect): error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
2017-05-18 22:08:49 [91807] 1dBTbE-000Nsg-Vq DANE attempt failed; no TLS connection to wrong.havedane.net [2001:1af8:4700:a118:90::7c0]
2017-05-18 22:08:50 [91807] 1dBTbE-000Nsg-Vq H=wrong.havedane.net [5.79.70.105] TLS error on connection (SSL_connect): error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
2017-05-18 22:08:50 [91807] 1dBTbE-000Nsg-Vq DANE attempt failed; no TLS connection to wrong.havedane.net [5.79.70.105]
2017-05-18 22:08:50 [91803] 1dBTbE-000Nsg-Vq == dc6f134be71d9a96 at wrong.havedane.net R=outbound_signed T=remote_dksign defer (-37) H=wrong.havedane.net [5.79.70.105]:25: failure while setting up TLS session
-----------------------------8< mainlog >8------------------------------

We might still have a corner case to handle, but the critical
functionality is all there, securing connections.

-Phil

From ietf-dane at dukhovni.org  Sun May 28 21:05:31 2017
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sun, 28 May 2017 19:05:31 +0000
Subject: Update on stats 2017-05
Message-ID: <20170528190531.GF22954@mournblade.imrryr.org>

As of today I count 169812 domains with correct DANE TLSA records
for SMTP.  As expected the bulk of the DANE domains are hosted the
handful of DNS/hosting providers who've enabled DANE support in
bulk for the domains they host.  The top 10 MX host providers by
domain count are:

   69614 domeneshop.no
   59404 transip.nl
   18372 udmedia.de
    6733 bhosted.nl
    1831 nederhost.net
     997 ec-elements.com
     501 core-networks.de
     339 bit.nl
     334 omc-mail.com
     309 uvt.nl

    [ The 365 "networking4all.net" domains from last month are
      gone, because they got bought by metaregistrar.nl and the
      new MX hosts are not in DNSSEC signed zones. Otherwise,
      the total would now have been over 170000. ]

The real numbers are surely larger, because I don't have access to
the full zone data for most ccTLDs, especially .no/.nl/.de.

There are 2567 unique zones in which the underlying MX hosts are
found, this counts each of the above providers as just one zone,
so is a measure of the breadth of adoption in terms of servers
deployed.  Alternatively, a similar number is seen in the count
(2667) of distinct MX host server certificates that support the
same ~169000 domains.  

A related number is 3818 TLSA RRsets found for MX host TCP port
25.  This includes secondary MX hosts and domains none of whose
primary MX hosts have TLSA records.

The number of domains that at some point were listed in Gmail's
email transparency report is 108 (this is my ad-hoc criterion for
a domain being a large-enough actively used email domain).  Of
these, 54 are in recent reports:

  anubisnetworks.com      gmx.de                  posteo.de
  asf.com.pt              gmx.net                 registro.br
  asp4all.nl              hr-manager.net          ruhr-uni-bochum.de
  bayern.de               ietf.org                samba.org
  bhosted.nl              isc.org                 solvinity.com
  bund.de                 jpberlin.de             t-2.com
  comcast.net             lrz.de                  t-2.net
  dd24.net                mail.com                t-2.si
  debian.org              mail.de                 torproject.org
  domeneshop.no           netbsd.org              trashmail.com
  elster.de               nic.br                  tum.de
  enron.email             nic.cz                  uni-erlangen.de
  fau.de                  octopuce.fr             unitymedia.de
  freebsd.org             open.ch                 web.de
  gentoo.org              openssl.org             webcruitermail.no
  gmx.at                  ouderportaal.nl         xfinity.com
  gmx.ch                  overheid.nl             xs4all.net
  gmx.com                 pathe.nl                xs4all.nl

Of the ~169000 domains, 749 have "partial" TLSA records, that cover
only a subset of the MX hosts.  While this protects traffic to some
of the MX hosts, such domains are still vulnerable to the usual
active attacks via the remaining MX hosts.

The number of domains with incorrect TLSA records or failure to
advertise STARTTLS (even though TLSA records are published) stands
today at 93.  The list of the 54 underlying MX hosts that serve
these domains and whose TLSA records don't match reality.

  Hall of Shame:

  mail.dipietro.id.au       mail.enzevalos.de     dorothy.goldenhairdafo.ne
  eumembers.stansoft.bg     hmserver.de           hs.kuzenkov.net
  catabra.com.br            mail.manima.de        oostergo.net
  server29.prazernavida.com www.mtg.de            ren.warunek.net
  mail.pgp.inf.br           mx1.spamsponge.de     cinnamon.nl
  my.mai1.ch                mail.0pc.eu           mail.e-rave.nl
  alpaca.attackllama.com    gamepixel.eu          mail.jekuiken.nl
  mail.danmolik.com         mx.quentindavid.fr    mail.myzt.nl
  mail.digitalwebpros.com   servmail.fr           bounder.steelyard.nl
  demo.liveconfig.com       mail.nonoserver.info  mx.wm.net.nz
  ny-do.pieterpottie.com    mx.datenknoten.me     beerstra.org
  diablo.sgt.com            mx.giesen.me          smtp.copi.org
  tusk.sgt.com              smtp.aechelon.net     eumembers.datacentrix.org
  mx1.wittsend.com          mail.castleturing.net smtp3.amadigi.ovh
  mx.bels.cz                mail.d3fy.net         mail.pasion.ro
  gaia.nfx.cz               datawebb.dafcorp.net  mail.lahl.rocks
  badf00d.de                anubis.delphij.net    protector.rajmax.si
  mail.denniseffing.de      goldenhairdafo.net    email.themcintyres.us

The number of domains with bad DNSSEC support is 438.  The increase is
due to a comprehensive scan of all 4.6 million DNSSEC domains in the
survey, previously some parts of the survey did not record SERVFAIL
results.

the top 10 DNS providers with problem domains are:

    68 jsr-it.nl
    58 infracom.nl	- Was slated to be resolved in March, delayed...
    27 is.nl
    24 active24.cz
    23 tiscomhosting.nl
    18 metaregistrar.nl
    15 rdw.nl
    10 firstfind.nl
     9 cas-com.net
     8 loopia.se

Around 50 of the broken domains have at least one working nameserver,
and so are email-reachable, given enough retries.  Only 6 of these
DNS-broken domains appear in historical Google Email transparency
reports:

  rzd.ru
  tse.jus.br
  tiviths.com.br
  trt1.jus.br
  trtrj.jus.br
  tjce.jus.br

The associated DNS lookup issues are:

  _25._tcp.ims1.rzd.ru. IN TLSA ? ; TLSA non-response: http://dnsviz.net/d/_25._tcp.ims1.rzd.ru/dnssec/
  _25._tcp.ims2.rzd.ru. IN TLSA ? ; TLSA non-response: http://dnsviz.net/d/_25._tcp.ims2.rzd.ru/dnssec/
  _25._tcp.lalavava.tse.jus.br. IN TLSA ? ; TLSA non-response: http://dnsviz.net/d/_25._tcp.lalavava.tse.jus.br/dnssec/
  _25._tcp.mx.tiviths.com.br. IN TLSA ? ; TLSA non-response: http://dnsviz.net/d/_25._tcp.mx.tiviths.com.br/dnssec/
  _25._tcp.mx1.trt1.jus.br. IN TLSA ? ; zone signature failure: http://dnsviz.net/d/_25._tcp.mx1.trt1.jus.br/dnssec/
  _25._tcp.mx1.trtrj.jus.br. IN TLSA ? ; zone signature failure: http://dnsviz.net/d/_25._tcp.mx1.trtrj.jus.br/dnssec/
  _25._tcp.mx2.tjce.jus.br. IN TLSA ? ; SOA signature failure: http://dnsviz.net/d/_25._tcp.mx2.tjce.jus.br/dnssec/

   [ See <https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-08>,
     Much of the TLSA non-response issue seems to be related to a
     "feature" of Arbor Networks firewalls, that enables droping
     of  DNS requests for all but the most common RRtypes.  Do not
     make the mistake of enabling this firewall "feature". ]

The oldest outstanding DNS issue is another SOA signature issue
at truman.edu dating back to Nov/2014:

  http://dnsviz.net/d/_25._tcp.barracuda.truman.edu/VGzORw/dnssec/

I hope some day soon they'll start missing email they care about
and take the time to resolve the problem.

-- 
	Viktor.