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

[Olafur Gudmundsson <[e-mail]>]

> On 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.
> 
Fine by me 

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

Barry, the working went down this path at one point and it turns quickly into a quicksand of special cases. 
For that reason we are not in base documents allowing TLSA w/o DNSSEC, 
Same goes for Service Records (SRV + MX) as if those are forged there is no value in TLSA for the forged 
servers. 
IMHO we should hold SRV and MX records to the same standard and IESG has blessed the SRV doc with
DNSSEC MUST, so I will object strongly to any attempt to lower the requirements. 

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

+1 

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

+1 

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

IMHO this just stating the obvious, it is harmless from a security perspective. 
If something like this is needed then maybe we need "TLSA for Dummies” statement. 
  DANE for SMTP requires the following: 
       - SMTP servers MUST support SSL, zone with MX record MUST be DNSSEC signed, 
       - at least one zone with mail server names MUST be DNSSEC signed, and the mail server name  MUST have TLSA records below it at  _xxx._smtp.<mail-server> 


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

Agree, 

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

+1

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

+1

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


Thanks Barry and Victor for careful review any good response 

Olafur