Subject: Re: [dane] WGLC: DANE-SRV & DANE-SMTP

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 17 Feb 2015 17:41:12 -0500

Dear wg members, 

This is a belated summary of the WGLC  (sorry my fault)
The SRV document got number of good reviews and editors have updated the document to reflect the comments received,
version -11 should be final WG version and we plan to advance it to the IESG. 

SMTP document did not get as many reviews, only 3 that I can see Paul Hoffman (no comments), Dan York (not a thorough review) and Sean Turner,
who had number of comments. There github repository contains a version of the document that addresses all the comments received. 
Editors please post ASAP. 
Chairs plan on advancing this document as well, but we would really like if couple of people take a fresh look and tell us the document is as ready as we think it is. 

Both the SRV and SMTP document have a dependency relationship with -OPS document thus we will start a WGLC on that document in the near future, 

   Olafur 

> On Nov 12, 2014, at 11:09 PM, Olafur Gudmundsson <[email-masked]> wrote:
> 
> Dear wg members
> 
> This email message starts a three week WGLC ending on December 4’th at 23:59 UTC. 
> 
> http://tools.ietf.org/wg/dane/draft-ietf-dane-srv <http://tools.ietf.org/wg/dane/draft-ietf-dane-srv>
> and 
> https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13 <https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13>
> 
> These two document are specifying related uses of DANE. 
> Please review the documents carefully, in particular we want to make sure the documents have no 
> contradictions. 
> 
> We need at least 5 members of the working group to state in public that they have read the documents and 
> state what is needed to fixed before the documents are advanced. 
> 
> I will act as document shepherd for these two documents. 
> 
> Olafur & Warren
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 20 Feb 2015 22:09:21 +0000

On Tue, Feb 17, 2015 at 05:41:12PM -0500, Olafur Gudmundsson wrote:

> The SRV document got number of good reviews and editors have updated the
> document to reflect the comments received, version -11 should be final WG
> version and we plan to advance it to the IESG.

Great, thanks!

> SMTP document did not get as many reviews, only 3 that I can see Paul
> Hoffman (no comments), Dan York (not a thorough review) and Sean Turner,
> who had number of comments.

Perhaps some folks [hint, hint] can return the favour and review
the SMTP draft in full. :-)

> The github repository contains a version of the document that addresses
> all the comments received.  Editors please post ASAP.

A -14 version has been pushed.  I've not yet received any feedback on
the possibility of extending the operational considerations section
based on the last few months of operational experience.  Please
advise...

On Thu, Jan 08, 2015 at 01:15:29AM +0000, Viktor Dukhovni wrote:

> [...]
>
> I did ask a question during LC:
> 
>     http://www.ietf.org/mail-archive/web/dane/current/msg07159.html
> 
>     ...
> 
>     One deployment pitfall discovered in recent interoperability tests
>     is that some domains have cleartext-only anti-spam proxies in front
>     of their MTA, with the proxies only allowing connections to the
>     real MTA once the SMTP client passes a grey-listing check (this
>     was observed with "spamd" as the proxy, but any "selective access"
>     to TLS can be similarly problematic).
> 
>     If the receiving domain publishes TLSA records, this creates a
>     catch-22 with DANE-aware client MTAs.  The DANE client never begins
>     the first mail transaction, because the proxy does not offer
>     STARTTLS, (the proxy is a receiving system deployed downgrade to
>     cleartext MiTM in front of the real MTA).
> 
>     The short-term solution for such domains is to NOT publish TLSA
>     RRs for port 25.  Longer-term the anti-spam proxy should be upgraded
>     to support STARTTLS.  For example, the Postfix "postscreen" service,
>     which has functionality similar to "spamd", supports STARTTLS so that
>     grey-listing does not amount to a similar downgrade attack.
> 
>     I'd like to add some language about avoiding this problem in the
>     operational considerations section of the smtp-with-dane draft.
>     Any objections?  
> 
>     Additional operational considerations might include not forgetting
>     to update TLSA RRs for *all* the names under which a server might
>     be known when doing key rotation.  This is a problem particularly
>     when a single wild-card certificate is deployed on all the MX hosts,
>     and replaced concurrently on them all, creating an immediate outage
>     for any domains that use variant MX host names (for flexibility of
>     later hosting some domains separately).  With DANE one should
>     strongly consider per-server certificates to avoid synchronized
>     multi-MTA outages.
> 
>     And lastly, by far the most common problems are with DNSSEC.  A
>     mixture of failure to perform timely re-signing and at present lots
>     of domains with nameservers that have non-working Denial of Existence.
>     I don't have a comprehensive list of software that is deficient in
>     this manner, but it seems that some older versions of PowerDNS
>     botch DoE in at least some configurations.  Similar issues reportedly
>     with djbdns DNSSEC patches.  A few domains have firewalls that
>     block TLSA queries, one blocked these only for IPv4 clients, with
>     IPv6 clients not filtered, that can create difficult to diagnose
>     problems.
> 
>     So I am looking for guidance on how much *current* operational
>     experience to include in the draft that may ultimately become
>     irrelevant as the infrastructure improves, but may be very useful
>     to get us past the initial deployment hurdles.  If we don't get
>     early adopters past the initial problems, the long-term obsolescence
>     of the issues might remain forever in the future.
> 
> Any feedback on that would be appreciated, plus guidance on *when* to
> make any such changes.

-- 
	Viktor.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 20 Feb 2015 17:13:01 -0500

Dear colleagues 
please take a few minutes to review this document if you have not done so yet. This
is a critical document from the working group and the chairs rather want the WG to find any
issues then in IETF last call. 

We plan to start a WGLC on the related OPS document RSN and will live with cross references between the
documents as they will all be published at the same time 

 Olafur

> On Feb 20, 2015, at 5:09 PM, Viktor Dukhovni <[email-masked]> wrote:
>

---

From: Brian Dickson <[email-masked]>
Date: Fri, 20 Feb 2015 21:32:27 -0800

I have read the documents, and do not see any glaring problems.
I support publishing them.

Brian

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 28 Feb 2015 21:48:27 +0000

> based on the last few months of operational experience.  Please

Perhaps making this more concrete will help.  I can publish a -15
with the following changes:

    * In Publisher Operational considerations again mention the need to avoid
      PKIX-TA/PKIX-EE 

    * In Publisher Operational considerations note that DANE TLSA and
      MTAs that only offer STARTTLS selectively (e.g. to client that
      pass greylisting) don't mix.

    * Note that some software cannot send root trust-anchors, if so
      the server TLSA records need to list an intermediate CA or use
      DANE-EE(3).

    * In section 3.1.3 note that the SHOULD NOT for PKIX-TA/PKIX-EE
      applies only to MTA-to-MTA SMTP, and MUA-to-MSA is not in scope.

FYI, the current main culprit for selective STARTTLS is "spamd",
and its authors are reputedly working on STARTTLS support to address
the issue!  The software simply had no STARTTLS support, and handles
the first transaction with a new client before allowing connections
to the real MTA.  There was no intention to specifically deny TLS
to new clients.

As for inability to send the root CA, reportedly that's an issue
with Microsoft Exchange, where either the Exchange software or
Schannel or both cannot be configured to put the root CA cert on
the wire.  Have not tried this myself.

The XML diff is below my signature.  Most of the operational issues
over the last few month are not SMTP specific, and the corresponding
operational guidace will be added to the OPS draft.

Should I add these to -15 before IETF LC?

-- 
	Viktor.

diff --git a/draft-ietf-dane-smtp-with-dane b/draft-ietf-dane-smtp-with-dane
index 55d6be3..60eff9e 100644
--- a/draft-ietf-dane-smtp-with-dane
+++ b/draft-ietf-dane-smtp-with-dane
@@ -1311,10 +1311,20 @@ path length or name constraints.
 
 </section><!-- Certificate usage 2 -->
 
-<section title="Certificate usages PKIX-TA(0) and PKIX-EE(1)">
+<section title="Certificate usages PKIX-TA(0) and PKIX-EE(1)" anchor="pkix-usages">
 
+<t>
+Note, this section applies to MTA-to-MTA SMTP on port 25.  That is,
+to servers that are the SMTP servers for one or more destination
+domains.  Other uses of SMTP, such as in MUA-to-MSA submission on
+ports 587 or 465 are out of scope for this document.  Where those
+other uses also employ TLS opportunistically and/or depend on DNSSEC
+as a result of DNS-based discovery of service location, the relevant
+specifications should, as appropriate, arrive at similar conclusions.
+</t>
+
 <t>
-As noted in the introduction, SMTP clients cannot, without relying
+As noted in the introduction, sending MTAs cannot, without relying
 on DNSSEC for secure MX records and DANE for STARTTLS support
 signaling, perform server identity verification or prevent STARTTLS
 downgrade attacks.  The use of PKIX CAs offers no added security
@@ -1324,12 +1334,13 @@ convenient non-PKIX certificate usage.
 </t>
 
 <t>
-SMTP servers SHOULD NOT publish TLSA RRs with certificate usage
-PKIX-TA(0) or PKIX-EE(1).  SMTP clients cannot be expected to be
-configured with a suitably complete set of trusted public CAs.
-Lacking a complete set of public CAs, clients would not be able to
-verify the certificates of SMTP servers whose issuing root CAs are
-not trusted by the client.
+Therefore, TLSA records for the port 25 SMTP service used by client
+MTAs SHOULD NOT include TLSA RRs with certificate usage PKIX-TA(0)
+or PKIX-EE(1).  SMTP client MTAs cannot be expected to be configured
+with a suitably complete set of trusted public CAs.  Lacking a
+complete set of public CAs, MTA clients would not be able to verify the
+certificates of SMTP servers whose issuing root CAs are not trusted
+by the client.
 </t>
 
 <t>
@@ -1734,10 +1745,31 @@ that server.
 <section anchor="oppublishers" title="Publisher Operational Considerations">
 
 <t>
+As explained in <xref target="pkix-usages"/> server operators SHOULD
+NOT publish TLSA records for their MTAs (port 25 SMTP) with certificate
+usages PKIX-TA(0) or PKIX-EE(1).
+</t>
+
+<t>
+Some MTAs enable STARTTLS selectively.  For example they might only
+support STARTTLS with clients that have previously demonstrated
+"proper MTA behaviour", for example by retrying the delivery of
+deferred messages (greylisting).  If such an MTA publishes DANE
+TLSA records, sending MTAs that implement this specification will
+not attempt the initial cleartext SMTP transaction needed to
+establish the "proper MTA behaviour", because they cannot establish
+the required channel security.  Server operators MUST NOT implement
+selective STARTTLS if they also want to support DANE TLSA.
+</t>
+
+<t>
 SMTP servers that publish certificate usage DANE-TA(2)
 associations MUST include the TA certificate in their TLS server
 certificate chain, even when that TA certificate is a self-signed
-root certificate.
+root certificate.  With some SMTP server software it is not possible to
+include root CA certificates in the server chain.  Such servers need to
+either publish DANE-TA(2) records for an intermediate certificate or
+to use DANE-EE(3).
 </t>
 
 <t>

---

From: James Cloos <[email-masked]>
Date: Sat, 28 Feb 2015 18:05:53 -0500

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

VD>     * In Publisher Operational considerations again mention the need
VD>       to avoid PKIX-TA/PKIX-EE

Do mention that the reason is that most MXs do not configure the OS's CA
suite by default, and most operators leave that as is.  Ie, that it is
not a fundamental limitation of SMTP but rather a nearly ubiquitous
reality of how they are configured for port 25.

VD>     * In Publisher Operational considerations note that DANE TLSA and
VD>       MTAs that only offer STARTTLS selectively (e.g. to client that
VD>       pass greylisting) don't mix.

+inf on that!

VD>     * Note that some software cannot send root trust-anchors, if so
VD>       the server TLSA records need to list an intermediate CA or use
VD>       DANE-EE(3).

Also helpful.

VD>     * In section 3.1.3 note that the SHOULD NOT for PKIX-TA/PKIX-EE
VD>       applies only to MTA-to-MTA SMTP, and MUA-to-MSA is not in scope.

VD> Should I add these to -15 before IETF LC?

+1.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6