On 20 Jul 2017, at 20:54, Daniel Margolis wrote:
Hey, Chris,
Thanks for the thorough review. A few inline comments off the cuff;
others
we will have to address in the draft.
On Thu, Jul 20, 2017 at 6:02 PM, Chris Newman
<[email protected]>
wrote:
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.
Do you have any suggestions of a restructuring? The current structure
is
(of course) _intended_ to be natural, in that we start with how to
discover
a policy (i.e., for senders, how to publish a policy), then how to
validate
a policy (i.e., for senders, how to decide what should go in your
policy),
then how to apply a policy (i.e. what the different "mode" options
mean and
how they affect delivery).
I'm not at all averse to changing it, but it would help us a bit to
have
more specific suggestions, if you have any. I and the other authors
obviously intended this to be a natural flow, so we may not be in the
best
position to see what is awkward about it. :)
I can't work through more precise suggestions at the moment.
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:
I think Appendix 2 covers more or less this, but in pseudocode. Are
you
suggesting that it would be better to have that be textual rather than
pseudocode, be in-document rather than an appendix, or both?
Both.
Example:
recipient: [email protected]
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?
Yes. The security value of OCSP is contentious (e.g.
https://www.imperialviolet.org/2014/04/19/revchecking.html) and
support for
it in HTTPS client libs is (AFAICT) haphazard; e.g.
https://curl.haxx.se/libcurl/c/CURLOPT_SSL_VERIFYSTATUS.htmlhttps://stackoverflow.com/questions/25803455/how-to-add-ocsp-support-into-python-requests-library.
Making OCSP a MUST seems to make implementation harder for
questionable
gain.
I never suggested MUST OCSP, I suggested SHOULD implement some mechanism
to check certificate revocation. From my perspective, it doesn't have to
be any mechanism in particular, but having no way to revoke certificates
is a problem. There have been real world cases where certificate
revocation was needed. It's possible software update mechanisms have
been more effective than other revocation mechanisms in practice, so
that may be sufficient to meet the recommendation.
- Chris
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
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
