Hi Alex,
On 28/06/2017 12:56, Brotman, Alexander wrote:
Most of these seem reasonable, and we'll get to work sorting them out. The
only question I have is relating to:
--------------
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 set possibly extensible?
If yes, you probably need a new IANA registry.
If not, you should say so.
-----------------
Sure, this set could be extended at some point in the future, but couldn't it
be addressed by a minor edit to the draft?
Once this document is published as an RFC, you will need to do that in
another draft. But yes, this would be fine.
I wouldn't think the number of possible values would be largely expanded, if
ever.
--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
x5364
-----Original Message-----
From: Uta [mailto:[email protected]] On Behalf Of Alexey Melnikov
Sent: Wednesday, June 28, 2017 6:03 AM
To: [email protected]
Subject: [Uta] AD review of draft-ietf-uta-smtp-tlsrpt-06.txt
You can treat these comments as WGLC comments:
4.4. JSON Report Schema
The JSON schema is derived from the HPKP JSON schema [RFC7469] (cf.
Section 3)
{
"organization-name": organization-name,
"date-range": {
"start-datetime": date-time,
"end-datetime": date-time
},
"contact-info": email-address,
"report-id": report-id,
"policy": {
"policy-type": policy-type,
"policy-string": policy-string,
"policy-domain": domain,
"mx-host": mx-host-pattern
},
"summary": {
"success-aggregate": total-successful-session-count,
"failure-aggregate:" total-failure-session-count
}
"failure-details": [
{
"result-type": result-type,
"sending-mta-ip": ip-address,
"receiving-mx-hostname": receiving-mx-hostname,
"receiving-mx-helo": receiving-mx-helo,
"session-count": failed-session-count,
"additional-information": additional-info-uri,
"failure-reason-code": "Text body"
I think you should replace "Text body" with failure-reason-code here.
}
]
}
JSON Report Format
o "organization-name": The name of the organization responsible for
the report. It is provided as a string.
o "date-time": The date-time indicates the start- and end-times for
the report range. It is provided as a string formatted according
to Section 5.6, "Internet Date/Time Format", of [RFC3339]. The
report should be for a full UTC day, 0000-2400.
o "email-address": The contact information for a responsible party
of the report. It is provided as a string formatted according to
Section 3.4.1, "Addr-Spec", of [RFC5322].
o "report-id": A unique identifier for the report. Report authors
may use whatever scheme they prefer to generate a unique
identifier. It is provided as a string.
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 set possibly extensible?
If yes, you probably need a new IANA registry.
If not, you should say so.
o "policy-string": The JSON string serialization ([RFC7159] section
7) of the policy, whether TLSA record ([RFC6698] section 2.3) or
MTA-STS policy.
o "domain": The Policy Domain is the domain against which the MTA-
STS or DANE policy is defined.
Need to make it clear that U-labels are not used here (unless they are!).
For example, add:
In the case of Internationalized Domain Names
([RFC5891]), the domain is the Punycode-encoded A-label
[RFC3492] and not the U-label.
o "mx-host-pattern": The pattern of MX hostnames from the applied
policy. It is provided as a string, and is interpreted in the
same manner as the "Checking of Wildcard Certificates" rules in
Section 6.4.3 of [RFC6125].
Similar comment about [non-]use of U-labels.
o "result-type": A value from Section 4.3, "Result Types", above.
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: RFC 5952 for IPv6 notation and reference "IPv4address"
ABNF non terminal for IPv4.
o "receiving-mx-hostname": The hostname of the receiving MTA MX
record with which the sending MTA attempted to negotiate a
STARTTLS connection.
o "receiving-mx-helo": (optional) The HELO or EHLO string from the
banner announced during the reported session.
o "success-aggregate": The aggregate number (integer) of
successfully negotiated TLS-enabled connections to the receiving
site.
In all other cases you describe the right hand side (the data type).
So should you use "total-successful-session-count" here?
o "failure-aggregate": The aggregate number (integer) of failures to
negotiate an TLS-enabled connection to the receiving site.
In all other cases you describe the right hand side (the data type).
So should you use "total-failure-session-count" here?
o "session-count": The number of (attempted) sessions that match the
relevant "result-type" for this section.
In all other cases you describe the right hand side (the data type).
So should you use "failed-session-count" here?
o "additional-info-uri": An optional URI pointing to additional
Add a reference.
information around the relevant "result-type". For example, this
URI might host the complete certificate chain presented during an
attempted STARTTLS session.
Are any specific URI types mandatory to implement? E.g. "http" and "https"?
o "failure-reason-code": A text field to include an TLS-related
error code or error message.
In Section 5.3:
5.3. Email Transport
The report MAY be delivered by email. To make the reports machine-
parsable for the receivers, we define a top-level media type
"multipart/report" with a new parameter "report-type="tlsrpt"".
Inside it, there are two parts: The first part is human readable,
typically "text/plain", and the second part is machine readable with
a new media type defined called "application/tlsrpt+json". If
compressed, the report should use the media type "application/
tlsrpt+gzip".
In addition, the following two new top level message header fields
are defined:
TLS-Report-Domain: Receiver-Domain
TLS-Report-Submitter: Sender-Domain
I would like to see a statement that these fields MUST be included.
These message headers would allow for easy searching for all reports
submitted by a report domain or a particular submitter, for example
in IMAP:
Please add a reference to RFC 3501 for IMAP here.
"s SEARCH HEADER "TLS-Report-Domain" "example.com""
6.1. Message headers
Below is the Internet Assigned Numbers Authority (IANA) Permanent
Message Header Field registration information per [RFC3864].
Header field name: TLS-Report-Domain
Applicable protocol: smtp
Per
<https://www.iana.org/assignments/message-headers/message-headers.xhtml#perm-headers>
this should be "mail" instead of "smtp".
Status: standard
Author/Change controller: IETF
Specification document(s): this one
Header field name: TLS-Report-Submitter
Applicable protocol: smtp
As above.
Status: standard
Author/Change controller: IETF
Specification document(s): this one
In Section 6.3:
As you are registering 2 different MIME types, you need to have 2 registration
templates, because considerations for JSON and GZIP are slightly different.
In Section 6.4:
You need to specify IANA registration policy from choices listed in RFC 5226. Most likely you want
"Specification Required" or "Expert Review"
(both imply expert review).
So you need to replace the last sentence of this section:
OLD:
New result types can be added to this registry without the
need to update this document.
NEW:
New result types can be added to this registry using
"Expert Review" IANA registration policy.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
