[dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT)

["Barry Leiba" <[e-mail]>]

Barry Leiba has entered the following ballot position for
draft-ietf-dane-smtp-with-dane-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Nothing fundamental here; I just have three things I'd like to sort out
before balloting "yes" on this, and they should all be easy to resolve:

1. References and terminology:
You use RFC 1034 to define "RR", and RFC 5598 to define "MSA", "MTA", and
"MUA".  And these are definitions that must be understood in order to
properly understand this document.  I think that makes those normative
references, not informative ones, and they should be changed.  (5598 is
already in the downref registry, so,there's no problem with the downref
here.)

2. Section 2.2.1 says this:

   That said, the protocol in this memo is
   an "opportunistic security" protocol, meaning that it strives to
   communicate with each peer as securely as possible, while maintaining
   broad interoperability.  Therefore, the SMTP client MAY proceed 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.

That makes sense.  Why doesn't the same thing apply for insecure TLSA
records?  Section 2.2 says that when TLSA records are insecure, you don't
use them, and SHOULD use pre-DANE security.  Please explain why they
shouldn't use insecure TLSA records for opportunistic encryption.

3. In Section 2.2.1:

   When DANE TLS is mandatory (Section 6) for
   a given destination, delivery MUST be delayed when the MX RRSet is
   not "secure".

This contradicts the "delivery MAY proceed" in the previous paragraph
(and it also doesn't really fit into the paragraph about logging anyway).
 If you want to restrict things, I think you should put the most
restrictive condition first, so move this sentence to the top of the
previous paragraph this way:

OLD
   If the MX RRSet (or any CNAME leading to it) is "insecure" (see
   Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via
   pre-DANE opportunistic TLS.
NEW
   If the MX RRSet (or any CNAME leading to it) is "insecure" (see
   Section 2.1.1), then if DANE TLS is mandatory (Section 6) for
   the given destination, delivery MUST be delayed.  If DANE TLS
   is not mandatory, then it need not apply, and delivery MAY proceed
   via pre-DANE opportunistic TLS.
END


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-- Section 2.2 --

   contrast, DNSSEC validated TLSA records MUST NOT be published for
   servers that do not support TLS.  Clients can safely interpret their
   presence as a commitment by the server operator to implement TLS and
   STARTTLS.

I don't know that this needs any text changes, though perhaps a mention
of this in the Security Considerations would be good: I'm not sure how
"safely" they will be able to do that in practice.  Remember that the
people running the email severs often have no connection to the people
who will insert or remove the TLSA records from the DNS.  It's possible
that a software change in the mail servers will remove support for DANE,
and the TLSA record will not be correspondingly removed.

I'm hoping that once this really gets rolled out, that won't be a real
issue, but it could be for a while.  It might be worth saying in the
Security Considerations that such a situation needs to be avoided, and
coordination is important, to make sure it doesn't happen.  Otherwise,
according to Section 2.2, mail delivery from DANE-aware MTAs will fail.

-- Sections 2.2.1 and 2.2.2 --

In 2.2.1:
   In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset
   is not "insecure" then it is "secure", and the SMTP client MUST treat
   each MX hostname as a separate non-MX destination for opportunistic
   DANE TLS (as described in Section 2.2.2).

In 2.2.2:
   This section describes the algorithm used to locate the TLSA records
   and associated TLSA base domain for an input domain that is not
   subject to MX resolution or that lacks MX records.

I find this combination unnecessarily confusing -- it starts to sound a
bit like Fizzbin
<http://en.wikipedia.org/wiki/List_of_games_in_Star_Trek#Fizzbin>.  I
know it's explained further (which is why this isn't a DISCUSS point),
but I think clarity in the introduction would help a lot.  I suggest
this, but anything similar would be equally helpful:

NEW
   In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset
   is not "insecure" then it is "secure", and the SMTP client MUST treat
   each MX hostname as described in Section 2.2.2.
END

NEW
   This section describes the algorithm used to locate the TLSA records
   and associated TLSA base domain for an input domain that is not
   subject to MX resolution, that represents a hostname from a secure MX
   RRset, or that lacks MX records.
END

That latter ordering matches the order of the bullet list, and I think
that's useful for making the text understandable.  You might also
re-think the title for Section 2.2.2, but I think that's less important.

-- Section 2.2.3 --

   If the ultimate response is a "secure" TLSA RRSet, then the candidate
   TLSA base domain will be the actual TLSA base domain and the TLSA
   RRSet will constitute the TLSA records for the destination.  If none
   of the candidate TLSA base domains yield "secure" TLSA records then
   delivery MAY proceed via pre-DANE opportunistic TLS.  SMTP clients
   MAY elect to use "insecure" TLSA records to avoid STARTTLS downgrades
   or even to skip SMTP servers that fail authentication, but MUST NOT
   misrepresent authentication success as either a secure connection to
   the SMTP server or as a secure delivery to the intended next-hop
   domain.

When SMTP clients elect to use insecure TLSA records, this text implies,
but doesn't make it completely clear, that they should only do that after
checking all candidates.  It would be good to be clear: check all
candidates, stopping at the first secure TLSA.  If no candidates produce
secure TLSA, then you MAY use an insecure one, or you MAY use pre-DANE
TLS.  Is that right?

In general, I strongly encourage you to review Section 2.2.3 and make
sure that it reads smoothly to someone who's not already familiar with
the DANE SMTP work.  I'm not sure the organization of the thoughts in
this section is very good as it's currently written.

-- Section 3.1 --

   In summary, we RECOMMEND the use of either "DANE-EE(3) SPKI(1)
   SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records
   depending on site needs.

But later, in Section 3.1.1, you specifically single out the former:

   TLSA records published for SMTP servers SHOULD, in most cases, be
   "DANE-EE(3) SPKI(1) SHA2-256(1)" records.

To be more consistent in your advice, I suggest changing the advice in
3.1 thus:

NEW
   In summary, we RECOMMEND the use of "DANE-EE(3) SPKI(1)
   SHA2-256(1)", with "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA
   records as a second choice, depending on site needs. See
   the following two subsections for more details.
END

If that's not the advice you mean to give, then something is unclear.

-- Section 3.1.1 --

   Similarly, the expiration date of the server certificate MUST be
   ignored, the validity period of the TLSA record key binding is
   determined by the validity interval of the TLSA record DNSSEC
   signature.

Editorial: "Similarly" to what?  I'd remove the word.  Also, the comma
after "ignored" needs to be a colon (or a semicolon, but I think a colon
is better here; the comma splice is just wrong).

   With DANE-EE(3) servers need not employ SNI (may ignore the client's
   SNI message) even when the server is known under independent names

Editorial: This needs a comma after "DANE-EE(3)", and would do well with
"they" before "may ignore").

-- Section 3.1.1 --

   Such servers MUST either publish DANE-TA(2)
   records for an intermediate certificate or MUST instead use DANE-
   EE(3) TLSA records.

The first "MUST" should be moved one word later, after "either" (or else
the second "MUST" should be removed).

-- Section 3.1.3 --

   Note, this section applies to MTA-to-MTA SMTP on port 25.

Earlier, in 2.2.3, you note that "the destination TCP port is typically
25, but this may be different with custom routes specified by the MTA
administrator".  I don't think you mean for this section not to apply in
the latter case, so I suggest changing this to, "Note, this section
applies to MTA-to-MTA SMTP, which is normally on port 25."

   Nothing is lost since the
   PKIX certificate usages cannot aid SMTP TLS security, they can only
   impede SMTP TLS interoperability.

Editorial: You need a comma after "lost", and the existing comma needs to
be a semicolon.

The last paragraph of the section is missing a final period.

-- Section 6 --

   Administrators of mail servers that employ mandatory DANE TLS, need
   to carefully monitor their mail logs and queues.

Nit: the comma should be removed.