[Uta] AD review of draft-ietf-uta-smtp-tlsrpt-04.txt

[Alexey Melnikov <[e-mail]>]

Hi,

I've done an early Area Director-style review of the document. Some of 
the issues I found in -03 were already fixed in -04.


In Section 1:

    Specifically, this document defines a reporting schema that covers
    failures in routing, STARTTLS negotiation, and both DANE [RFC6698]
    and MTA-STS (TODO: Add ref) policy validation errors, and a standard

Such references should be fixed. Which format are you using for editing 
the document?

    TXT record that recipient domains can use to indicate where reports
    in this format should be sent.

<<Is any alignment with MUA-STS needed?>>

    This document is intended as a companion to the specification for
    SMTP MTA Strict Transport Security (MTA-STS, TODO: Add ref).

In 1.1:

  TLS needs a reference.


In Section 2:

  You list related technologies, but don't mention how they relate to 
this document or why you need a new format. Can you add a sentence or 
two on this?
  After reading this section my initial reaction is "why on Earth you 
are not using/extending one of existing mechanisms?".

In Section 3:

  HTTPS needs to be updated to point to [one of] the latest HTTP/1.1 RFC.

  mailto: URI needs a Normative Reference to RFC 6068.


  Do you want to mention something in this section about extensibility 
(e.g. in anticipation of addition of "ruf")? Unless "ruf" is gone for 
good, adding new values might be difficult otherwise. (And ideally this 
should also be reflected in the ABNF.)


In Section 4.3

  Is the list of result types extensible? If yes, you should create a 
new IANA registry, so that people can add new values, without the need 
to update this document.


4.3.3.  General Failures

    When a negotiation failure can not be categorized into one of the
    "Negotiation Failures" stated above, the reporter SHOULD use the
    "validation-failure" category.  As TLS grows and becomes more
    complex, new mechanisms may not be easily categorized.  This allows
    for a generic feedback category.  When this category is used, the
    reporter SHOULD also use the "failure-reason-code" to give some
    feedback to the receiving entity.  This is intended to be a short
    text field, and the contents of the field should be an error code or
    error text, such as "X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION".

Is this field human readable?


In Section 5.3:

"text/json" is not a registered MIME type. I think you meant 
"application/json".

  Why not define new email header fields? Encoding everything in Subject 
looks rather hackish.

  Also, why not define new JSON-based MIME type for reports? This will 
make it easier to process reports of different type addressed to the 
same email recipient.


Section 7:

    o  Flooding of the Aggregate report URI (rua) endpoint: An attacker
       could flood the endpoint and prevent the receiving domain from
       accepting additional reports.  This type of Denial-of-Service
       attack would limit visibility into STARTTLS failures, leaving the
       receiving domain blind to an ongoing attack.

  [...]

    o  Reports as DDoS: TLSRPT allows specifying destinations for the
       reports that are outside the authority of the Policy Domain, which
       allows domains to delegate processing of reports to a partner
       organization.  However, an attacker who controls the Policy Domain
       DNS could also use this mechanism to direct the reports to an
       unwitting victim, flooding that victim with excessive reports.
       DMARC [RFC7489] defines an elegant solution for verifying
       delegation; however, since the attacker had less ability to
       generate large reports than with DMARC failures, and since the

  Are these talking about the same issue? If yes, they should be merged 
or one of them should be deleted.


Section 9:

As this section is pretty much the most important section in the 
document, I am surprised that it is marked as Appendix. As a general 
comment, I think this section would benefit from more clarity about 
various syntaxes used. Some specific comments:

    o  "policy-type": The type of policy that was applied by the sending
       domain.  Presently, the only three valid choices are "tlsa",
       "sts", and the literal string "no-policy-found".  It is provided
       as a string.

Is this field case sensitive? If yes, it would be good to say so.

    o  "policy-string": The string serialization of the policy, whether
       TLSA record or STS policy.  Any linefeeds from the original policy
       MUST be replaced with [SP].  TODO: Help with specifics.

The definition is clearly unfinished.

    o  "domain": The Policy Domain upon which the policy was applied.
       For messages sent to "[e-mail]" this field would contain
       "example.com".  It is provided as a string.

Again, need references here. Are IDN domains (in UTF-8) allowed here?

    o  "ip-address": The IP address of the sending MTA that attempted the
       STARTTLS connection.  It is provided as a string representation of
       an IPv4 or IPv6 address in dot-decimal or colon-hexadecimal
       notation.

Need references for string representations of both types of IP addresses.

    o  "success-aggregate": The aggregate number (integer) of
       successfully negotiated SSL-enabled connections to the receiving
       site.

    o  "failure-aggregate": The aggregate number (integer) of failures to
       negotiate an SSL-enabled connection to the receiving site.

Please let's use "TLS" everywhere instead of "SSL". I found at least 3 
places.

Best Regards,

Alexey