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 "[email protected]" 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
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
