[Uta] TLSRPT review

[Viktor Dukhovni <[e-mail]>]

First: Since this draft is about SMTP security, references to DANE should
       be to RFC7672 not RFC6698.

=== 1.  Introduction

In the paragraph:

   The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and
   hosts to establish secure SMTP sessions over TLS.  The protocol
   design is based on "Opportunistic Security" (OS) [RFC7435], which
   provides interoperability for clients that do not support STARTTLS

s/provides/maintains/
s/for/with/

   but 

(absent downgrade-destination destination security policy, such as
DANE or, after initial contact, STS)

   means that any attacker who can delete parts of the SMTP session
   (such as the "250 STARTTLS" response) or redirect the entire SMTP
   session (perhaps by overwriting the resolved MX record of the
   delivery domain) can perform a downgrade or interception attack.

Would s/parts/stages/ be better in the below?

   Because such "downgrade attacks" are not necessarily apparent to the
   receiving MTA, this document defines a mechanism for sending domains
   to report on failures at multiple parts of the MTA-to-MTA
   conversation.

=== 1.1 Terminology:

In:

   o  DANE Policy: A mechanism for enabling the administrators of domain
      names to specify the keys used in that domain's TLS servers.  DANE
      is defined in [RFC6698]

I think 'administrators of domain names' is poor wording.  DANE policy
is specified by MTA operators, and published by the administrators of
the DNS zones in which the MTA hosts are found.  When the MX hosts of
a domain are operated by a third party, the DANE policy is published
by the MX host operator, all the domain owner has to do is use DNSSEC
to publish their MX records.

=== 3. Reporting Policy

In the below:

      *  In the case of "mailto", reports should be submitted to the
         specified email address.  When sending failure reports via
         SMTP, sending MTAs MUST NOT honor SMTP STS or DANE TLSA
         failures.

perhaps instead of "must not honor ... failures" it should be
"must deliver the report despite any ... failures".  I think
this means that even if there are multiple MX hosts, and a
failure is encountered with the first one, delivery proceeds
even though it may be possible to do more secure delivery via
one of the remaining MX hosts.  Also if the TLS handshake fails
(TLS interop issue), I would say that delivery should then be
retried in the clear (though perhaps as part of a retry, after
the report is initially deferred).  The idea is that reports
should get through even when STARTTLS is fails to establish
a handshake, not just completes with authentication errors.

In:

   o  "ruf": Future use.  (There may also be a need for enabling more
      detailed "forensic" reporting during initial stages of a
      deployment.  To address this, the authors consider the possibility
      of an optional additional "forensic reporting mode" in which more
      details--such as certificate chains and MTA banners--may be
      reported.)

I don't see the point of talking about "ruf", given that no
specification is proposed.  This should be deleted.

=== Section 4:

In:

      *  One of the following policy types: (1) The SMTP MTA STS policy
         applied (as a string) (2) The DANE TLSA record applied (as a
         string) (3) The literal string "no-policy-found", if neither a
         TLSA nor MTA-STS policy could be found. 

"The DANE TLSA record" is in fact an RRset, and a single string encoding
would be suboptimal, or at least needs a more precise specification.
Do you want the presentation form of the RRs separated by CRLF?  Do you
want these with "owner ttl class type rrdata" or just the rrdata? ...

Some of the DANE TLSA RRs might be "usable" and others "not usable",
which is which depends on the client.  Similarly, digest agility means
that the client might be ignoring some of the RRs.

What makes sense to me is to report either a non-empty set of usable
unignored RRs, or if all are unusable, the full set of RRs and an
indication that they are all unusable (in which case per RFC7672
the MTA would enforce the use of TLS, but without authentication).

=== 4.1.  Report Time-frame

Given the text:

   The report SHOULD cover a full day, from 0000-2400 UTC.  This should
   allow for easier correlation of failure events.

I'm inclined to conclude that TLSRPT is not an especially timely notification
mechanism.  Since on average problem reports will be 12 hours or so late.
Is there some provision for more timely notification, or will that need to be
done in-band (separate spec TBD)?

=== 4.3.1.  Routing Failures

Recent discussion of the STS draft suggests that the "mx" field in STS
really should become a "san" field instead, with MX choice unaffected
by the STS policy.  Fraudulent MX hosts will not be able (we hope) to
present certificates whose SANs match the STS policy.  If so:

   o  "mx-mismatch": This indicates that the MX resolved for the
      recipient domain did not match the MX constraint specified in the
      policy.

This error condition goes away, and is subsumed by failure to match
the certificate against any of the policy SAN values.  This is much
cleaner, but, full disclosure, this requires more sophistication
in the TLS peer-verification code to support such matching (rather
than just match the literal MX host).

Postfix can already do this, but for other MTAs this would be new code.
If they're using OpenSSL, then the library has the requisite hooks as
of OpenSSL 1.0.2 to match either a literal name or a sub-domain of a
parent domain from a set of such names or parent domains.

   https://www.openssl.org/docs/man1.0.2/crypto/X509_check_host.html

other toolkits might not yet support an equivalent feature.

=== 4.3.2.  Negotiation Failures

   o  "certificate-host-mismatch": This indicates that the certificate
      presented did not adhere to the constraints specified in the STS
      or DANE policy, e.g.  if the CN field did not match the hostname
      of the MX.

The "CN field" is long obsolete.  It would be great if STS required
compliant certificates to have a DNS SAN (rather than support legacy
CN per 6125).  The STS spec is new, and really should raise the bar
here.  I don't know of any CAs that omit DNS subject altnames these
days.  In any case the above text should talk about SANs primarily
and the CN only as an afterthought.

In the below:

   o  "certificate-not-trusted": This a label that covers multiple
      certificate related failures that include, but not limited to
      errors such as untrusted/unknown CAs, certificate name contraints,
      certificate chain errors etc.  When using this declaration, the
      reporting MTA SHOULD utilize the "failure-reason" to provide more
      information to the receiving entity.

"contraints" is a typo.

=== 4.3.3.1. DANE-specific Policy Failures

Keep in that the TLSA records are plural (an RRset) and that invalid
records are "unusable", and ignored so long as some usable records
are found.  So it is not clear what this is for, except perhaps
to signal that all the records are unusable.

   o  "tlsa-invalid": This indicates a validation error in the TLSA
      record associated with a DANE policy.

As for dnssec-invalid, that's simply a DNS lookup error, which
can lead to skipping the MX host or deferral of mail.  So the
condition is much too specific.  The typical MTA will never
see invalid DNSSEC replies, the resolver will just report SERVFAIL
in response to "_25._tcp.smtp.example.com. IN TLSA ?"

   o  "dnssec-invalid": This indicates a failure to authenticate DNS
      records for a Policy Domain with a published TLSA record.


=== 5.3 Email Transport

   Note that, when sending failure reports via SMTP, sending MTAs MUST
   NOT honor SMTP STS or DANE TLSA failures.

See above re "not honor", ...

-- 
	Viktor.