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

[Viktor Dukhovni <[e-mail]>]

On Sun, May 24, 2015 at 01:41:21PM -0700, Barry Leiba wrote:

> 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.)

No objections from me.  If nobody else objects, I'll move these to
normative in a few days.

> 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.

If I recall correctly, the working group was concerned about diluting
the otherwise clear position that TLSA should not be used without
DNSSEC.

In the context this draft alone, the main reason to avoid using
TLSA records from insecure zones, is that lookups of such records
are prone to failures (with long timeouts while trying all NS
records) against "bare-bones" nameservers that support neither
DNSSEC nor TLSA records.

When the MX RRset is secure, but the A/AAAA records are insecure,
no TLSA lookup takes place.  I think that proceeding with (soft-fail)
TLSA lookups when the MX RRset is insecure invites implementation
errors.

> 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

Thanks, this is a big improvement.  Perhaps the "MAY proceed" should
probably also be clarified.  The intention is to note the possibility
of using pre-DANE TLS (which is not required, cleartext is also
allowed).  It is not the intention of this text to make using the
MX host optional.  Delivery, with or without TLS, MUST be attempted.

So perhaps better still:

    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 DANE does not apply and delivery proceeds
       with pre-DANE opportunistic TLS (perhaps even in cleartext).
    END

> -- Section 2.2 --
> 
>    ... 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.

Indeed the "safely" is the result of the server mandate, and also the
problems servers will incur when they mess up, once this protocol is
adopted sufficiently widely.  So "safely" is somewhat forward-looking.
Should such a note be in "Security" or "Operational" considerations?
And is it really needed?

> 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.

We're on the same page, the only question is whether this is
sufficiently obvious to avoid needing to explain it.

> -- 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.
> 
> 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

Much better, thanks.  When would you like to see a new version with
these changes?  (I am guessing I should wait for any additional IESG
comments?)

> You might also
> re-think the title for Section 2.2.2, but I think that's less important.

I see what you mean, but nothing obvious comes to mind.  Is "Post-MX"
better than "Non-MX"?

> -- 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.

Thanks for highlighting this.  The same fix as above for "MAY
proceed via pre-DANE opportunistic TLS" should likely be applied
here.

> 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.

Yes.  There are at most two choices (before and after CNAME
expansion).  The expansion is tried first, and if that is not
secure, and there was in fact CNAME indirection, the origin MUST
be tried.  If the origin is secure, that MUST be used.

I can tweak this text for more clarity.

> 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?

Yes, and that "last" MAY, is really a "free to use TLS the old
way", but in any case MUST use the destination with whatever security
you can get.  No skipping of insecure MX hosts.  Adherence to MX
preference first, channel security second.

> 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.

Noted.  How should I communicate any proposed revisions?

> -- 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.

Indeed, these two are a sufficient best-practice set to cover all
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.

The vast majority of sites should (and do in fact among the early
adopters) stick to usage DANE-EE(3), the DANE-TA(2) case is for
select sites with an internal PKI (private CA) and lots of servers.

> 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

This works.  Thanks.

> -- 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).

Will do.

>    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").

Thanks.

> -- 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).

Thanks, no problem.

> -- 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."

Thanks.  Indeed that's the correct formulation.

>    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.

No worries.

> -- 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.

Thanks.

-- 
	Viktor.