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

[Barry Leiba <[e-mail]>]

Quick response for tonight, with a fuller one on Tuesday, NY time:
Thanks for the responses, Viktor and Olafur.  Between the two, you've
explained what I need for DISCUSS point 2.  Tomorrow I'll clear the
DISCUSS completely and give a better email response (short version:
all is good on all comments, and thanks).

As to when to post a revised I-D: my preference is always "early and
often", but you should check with Stephen, as he's the responsible AD.

Barry

On Sun, May 24, 2015 at 10:04 PM, Viktor Dukhovni
<[e-mail]> wrote:
> 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.
>