Overall, I find the document hard to read and the structure problematic.
If I'm verifying STS policy, I want to know how to fetch the policy,
then I want to know what to fetch. The document structure is awkward for
that goal. And if I want to publish STS policy, I want to know where I
publish it and then what I need to publish. An editorial pass to
reorganize the document to be more useful and clear for an implementer
would be helpful. There's also an overuse of "quotes" around terminology
which is problematic in a document with JSON strings which need to be
quoted in the context of protocol examples.
It'd be helpful to have an example workflow, possibly early in the
document. Something like:
Example:
recipient: u...@example.com
Determine policy domain [section reference], in this case example.com
Look up DNS TXT record in _mta-sts.example.com (_mta-sts TXT record in
policy domain). [section reference].
If failure or invalid record, stop.
If valid cached policy record, skip forward to SMTP connection.
Connect to https server at mta-sts.example.com (mta-sts host in policy
domain). [section reference]
Verify HTTPS TLS certificate as matching domain mta-sts.example.com
[section reference].
Fetch policy from /.well-known/mta-sts.json [section reference].
Connect to SMTP server according to SMTP standard.
Perform STARTTLS
Verify TLS negotiation and hostname matches STS policy [section
reference].
transmission into authenticated, downgrade-resistent encrypted
tarnsmission.
Fix spelling: resistent->resistant, tarnsmission => transmission
sts-version = %x76 *WSP "=" *WSP %x53 %x54 ; "v=STSv1"
%x53 %x76 %x31
I recommend you improve ABNF readability by referencing RFC 7405.
std-version = %s"v=STSv1"
The policy itself is a JSON [RFC7159] object served via the HTTPS
GET
This reference needs to be changed to draft-ietf-jsonbis-rfc7159bis, or
you need to explicitly require use of UTF-8 charset, or reference I-JSON
(RFC 7493). With RFC 7159 there's a requirement to support and detect
UTF-16LE, UTF-16BE, UTF-32LE, UTF-32BE charsets (and possibly other
Unicode encodings) that I find highly problematic for interoperability.
When fetching a new policy or updating a policy, the HTTPS endpoint
MUST present a X.509 certificate which is valid for the "mta-sts"
host (as described below), chain to a root CA that is trusted by the
After reading the document, I'm not sure I understand how to construct
the DNS FQDN that I need to pass to the TLS API in order to validate the
mta-sts host. In the example workflow above, I made a guess. But the
document presently never says how to construct the FQDN explicitly.
The certificate MAY be checked for revocation via the Online
Certificate Status Protocol (OCSP) [RFC2560], certificate revocation
lists (CRLs), or some other mechanism.
Is there a reason this is a MAY rather than a SHOULD?
3.4. Policy Selection for Smart Hosts and Subdomains
It's confusing to group two very different aspects of mail operations
into a single section. I'd suggest making this two sections.
certificate MUST have a CN-ID ([RFC6125]) or SAN ([RFC5280]) with a
The abbreviation "SAN" doesn't appear in RFC 5280. Please expand it to
subjectAltName which does appear.
DNS-ID matching the "mx" pattern. The MX's certificate MAY also be
checked for revocation via OCSP [RFC2560], certificate revocation
lists (CRLs), or some other mechanism.
Is there a reason this is a MAY rather than a SHOULD?
New fields are added to this registry using IANA's "Expert Review"
policy.
Please add some guidance to the expert reviewer on the criteria that
should be met when registering new fields. You can leave the reviewer
some wiggle room, but having guidance sets expectations for the person
registering the new field, the expert reviewer and for any IESG appeal
that might result from a disagreement.
8. Security Considerations
One more security consideration:
This mechanism causes an MTA (an automated system) to adopt the role of
an HTTPS client in a scenario where the HTTPS server may be hostile to
operation of the MTA. A full HTTP stack is a large amount of code that
may contain coding errors that expose the MTA to new implementation
vulnerabilities. This threat can be partially mitigated by using a
hardened HTTPS client library that has been tested against a fuzzing
HTTPS test server. This threat can also be partially mitigated by
isolating the HTTPS code into a separate process that does not have
access to the normal MTA machinery and making sure the MTA machinery
gracefully handles a wedged HTTPS client. Sites that are evaluating the
cost/benefit of this functionality may wish to compare the new attack
surface of this mechanism with the new attack surface of alternate
mechanisms such DANE [RFC7672].
- Chris
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
