On Sat, Mar 19, 2016 at 11:20:23AM +0100, Mark Risher wrote:
> The initial draft is at
> https://datatracker.ietf.org/doc/draft-margolis-smtp-sts/ and we hope to
> discuss this at the Buenos Aires meeting next month. While we have deployed
> a prototype/reference implementation among the authors, we are very open to
> feedback and suggestions from the broader group and look forward to your
> input.
I have some feedback.
Section 1. Introduction
<quote>
The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and
hosts to establish secure SMTP sessions over TLS. In its current
form, however, it fails to provide (a) message confidentiality --
because opportunistic STARTTLS is subject to downgrade attacks -- and
</quote>
More accurately, STARTTLS provides confidentiality only against
passive attacks, not in the face of active downgrade or MiTM attacks.
<quote>
While such "opportunistic" encryption protocols provide a high
barrier against passive man-in-the-middle traffic interception, any
attacker who can delete parts of the SMTP session (such as the "250
STARTTLS" response) or who can redirect the entire SMTP session
(perhaps by overwriting the resolved MX record of the delivery
domain) can perform such a downgrade or interception attack.
</quote>
Better to say:
While such Opportunistic Security (OS) protocols [RFC7435] protocols ...
(such as the "STARTTLS" keyword from the server's EHLO response) ...
(or perhaps by forging responses to DNS MX lookups) ...
Section 2.1. Differences from DANE
<quote>
In addition, SMTP STS introduces a mechanism for failure reporting
and a report-only mode, enabling progressive rollout and auditing
for compliance.
</quote>
Note that DANE definitely supports "progressive rollout",
senders who enable DANE will only attempt DANE authentication
for domains that have deployed DNSSEC and published TLSA records.
When a sender enables DANE, the use or non-use of TLS remains
unaltered for the vast majority of domains. This is of course
also the case for STS. There is no flag day in either case.
More critically, when a receiving domain publishes TLSA records,
it can do so progressively by publishing TLSA records for one
MX host at at a time, leaving some of the MX hosts unprotected.
Problems with authentication of the protected hosts will trigger
retries via the unprotected MX hosts. This is actually more
flexible than STS, which as defined cannot express a policy
that protects only a subset of the MX hosts. Once a domain
has published DANE TLSA RRs for all its MX hosts, then
authentication becomes mandatory. Of the ~11600 domains with
DANE TLSA records, around 200 have such "partial deployments"
in which some, but not all the MX hosts have TLSA records.
This is I believe an honest mistake resulting from a natural
focus on STS, and not a detailed analysis of DANE.
<quote>
In addition, SMTP STS introduces a mechanism for failure reporting
and a report-only mode, enabling progressive rollout and auditing
for compliance.
</quote>
More on this below, but I should note that I am looking forward
to an authentication-neutral definition reporting mechanism,
which can be used by either DANE or STS. Below I will propose
changes to the draft that will simplify and focus STS, and at
the same make the reporting feature equally usable with DANE.
Section 2.2. Advantages When Used with DANE
<quote>
SMTP STS can be deployed for a recipient domain that also publishes a
DANE TLSA record for SMTP. In these cases, the SMTP STS policy can
additionally declare a process for failure reporting.
</quote>
As noted above, the reporting feature (redefined as a stand-alone
component of STS below) should make a good fit for both STS
and DANE.
Section 2.3. Advantages When Used Without DANE
<quote>
When deployed without a DANE TLSA record, SMTP STS offers the
following advantages compared to DANE:
o _Infrastructure:_ In comparison to DANE, this proposal does not
require DNSSEC be deployed on either the sending or receiving
domain. (continued below)
</quote>
Agreed on non-requirement, with the stated security considerations...
<quote>
(contd.) In addition, the reporting feature of SMTP STS can be
deployed to perform offline analysis of STARTTLS failures,
enabling mail providers to gain insight into the security of their
SMTP connections without the need to modify MTA codebases
directly.
</quote>
Here, there is no need for any difference between DANE and STS,
if STS records (see below) enable reporting, DANE sending
systems will also be able to leverage said reporting. So this
is a feature of this draft that pertains to both technologies,
and thus would be a refinement for DANE, rather than a difference.
<quote>
o _Incrementalism:_ DANE does not provide a reporting mechanism and
does not have a concept of "report-only" for failures; as a
result, a service provider has no choice but to "flip the switch"
and affect the entire mail stream at once.
</quote>
This is the result of a misunderstanding, see above. This claim
should be removed.
Section 2.4. Disadvantages When Used Without DANE
<quote>
o Infrastructure: DANE may be easier for some providers to deploy.
In particular, for providers who already support DNSSEC, SMTP STS
would additionally require they obtain a CA-signed x509
certificate for the recipient domain.
</quote>
A significant obstacle to a successful roll-out of WebPKI with
SMTP is not such much that obtaining and deploying CA certs is
onerous (enabling DNSSEC is likely more difficult at present),
but rather that there is no single set of CAs that sending and
receiving systems can (or perhaps should) reasonably agree on.
On the one hand, because MTAs employing STS are non-interactive
background processes with no human-operator in the loop to
"click OK" for each exception, the set of CAs a sending system
that employs STS would need to trust would need to be "comprehensive
enough" to include all the CAs used by all the domains one
might need to send email to.
On the other hand, one's sensitive correspondence with one's
business partners, health care providers, ... should not
generally trust CAs operated by distant countries with a penchant
for surveillance (Kazakhstan comes to mind).
The real advantage of DANE is that it has baked-in name-constraints,
and repressive regimes only control DNS resolution for their
captive ccTLDs, and users are often free to register domains
in less censorious gTLDs.
<quote>
o Security: DANE offers an advantage against policy-lookup DoS
attacks; that is, while a DNSSEC-signed NX response to a DANE
lookup authoritatively indicates the lack of a DANE record, such
an option to authenticate policy non-existence does not exist when
looking up a policy over plain DNS.
</quote>
[s/NX/NXDOMAIN/]
Specifically, for domains to which a sending system sends email
infrequently, cached STS data may well expire before the next
message is sent. So not only 'first use', but also subsequent
traffic may be compromised by active attacks, even if the first
interaction (long enough in the past) was not compromised.
Section 3. Policy Semantics
<quote>
o mx: MX patterns (comma-separated list of plain-text MX match
patterns, required). One or more comma-separated patterns
matching the expected MX for this domain. For example,
"_.example.com,_.example.net" indicates that mail for this domain
might be handled by any MX whose hostname is a subdomain of
"example.com" or "example.net."
</quote>
This requires domains that publish STS records to duplicate
their MX records in the STS RRset. It is not clear why that's
useful. If the STS record itself is not DNSSEC-validated, the
payload is not more secure than the MX RRset. If the payload
is DNSSEC-validated, then the MX RRset in the same zone would
(barring unexpected zone cuts) be equally secure. I posit that
this field is both onerous and superfluous.
<quote>
o a: The mechanism to use to authenticate this policy itself. See
the section _Policy_ _Authentication_ for more details. Possible
values are:
* webpki:URI, where URI points to an HTTPS resource at the
recipient domain that serves the same policy text.
* dnssec: Indicating that the policy is expected to be served
over DNSSEC.
</quote>
Given that STS is primarily useful when at least one of the
sending or receiving domains does not support DNSSEC, it seems
clear that the "dnssec" mechanism is not needed. If both ends
support DNSSEC, just use DANE, it is more secure and in fact
more flexible (one MX at a time incremental deployment).
Since the receiving system should not suggest "dnssec" when
its own zone is unsigned, and has no information about the
sending system, it makes sense to simplify STS and drop the
"dnssec" mechanism. At which point, the webpki:URI becomes a
mandatory component, and the "webpki" tag is unnecessary. The
"a" component is always an HTTPS URI. The STS MX host patterns
to cache can be retrieved at that URI, and should/need not
appear in the STS record.
The URI itself needs to be a "well-known" URI, and therefore
it too can disappear from the STS record (STS is getting simpler
and simpler by the minute).
If the URI could be anywhere, an attacker could pin his own
long-term cached policy authenticated via an HTTPS URL hosted
at domain a of his choice.
With the URI fixed at https://example.com/.well-known/smtp-sts/current/
(as suggested in section 3.1), the entire "a" component becomes
redundant.
<quote>
o c: Constraints on the recipient MX's TLS certificate (plain-text,
required). See the section _Policy_ _Validation_ for more
details. Possible values are:
* webpki: Indicating that the TLS certificate presented by the
recipient MX will be validated according to the "web PKI"
mechanism.
* tlsa: Indicating that the TLS certificate presented by the
recipient MX will match a (presumed to exist) DANE TLSA record.
</quote>
Once again, if both systems are DNSSEC-capable, they should
use DANE. The receiving domain has no idea whether the sender
supports DANE, and so cannot reasonably suggest that alternative.
Therefore, this field is redundant and should be deleted. STS
is fundamentally reliant on WebPKI as an alternative DANE in
the absence of widespread DNSSEC deployment.
<quote>
o rua: Address to which aggregate feedback MAY be sent (comma-
separated plain-text list of email addresses, optional). For
example, "mailto:[email protected]"; from [RFC3986].
</quote>
This should likely be a separate DNS record. Say:
_smtp_rua.example.com IN <RRtype> <report-URI>
In which case some thought should be given to the URI encoding
(UTF-8?) and length considerations if a TXT RRtype is used.
With this the reporting address can be used with either DANE
or STS. It need not waste bandwidth in each STS lookup, it is
only needed on failure.
However (see below), since this is also vended via the required
STS policy WebPKI URI, it should then be removed from DNS,
simplifying the DNS record, to just:
v=... to=... e=...
An astute reader will at this point wonder why we need any
fields in DNS at all? Why not just delete the DNS record in
its entirety, and just go straight to the well known HTTPS URI?
If you were already there, congratulations, this is basically
the right idea, but there is *one bit* of information that
needs to remain in DNS. And that is whether the destination
domain operates an HTTPS service that vends an STS policy at
the well-known URI.
It would be expensive for MTAs to attempt repeated HTTPS
connections that timeout trying to connect to port 443 at
the majority of domains which have not deployed STS.
All that's needed in DNS to support a pure WebPKI STS is a
boolean value to signal the existence of the STS resource URI.
This data can be obtained efficiently. If the "_smtp-sts" RR
exists (pick a suitable RRtype and fixed short payload) then
the HTTPS URI should be consulted, otherwise the HTTPS URI is
not consulted (at first contact), or is consulted asynchronously,
in parallel with the first mail delivery (with appropriate spacing
between probes, ...).
Thus some MTAs might compress the STS DNS record to zero bits,
and just use asynchronous suitably spaced HTTPS probes to the
domains for which no policy is presently known. However the
1-bit encoding is likely better.
Given the above comments, I should note that the HTTPS payload
would[ now be the only place where STS policy details are
stored. The data would then for greater convenience be JSON
encoded.
Section 3.2. Policy Expirations
With the DNS payload compressed to <= 1 bits, the DNS TTL is
no longer especially pertinent, the policy expiration can be
carried in the JSON encoding, or simply in the Cache policy
headers of the HTTP response.
Section 3.3. Policy Authentication
<quote>
o Web PKI: In this mechanism, indicated by the "webpki" value of the
"a" field, the sender fetches a HTTPS resource from the URI
indicated. For example, a=webpki:<https://example.com/.well-
known/smtp-sts/current> indicates that the sender should fetch the
resource <https://example.com/.well-known/smtp-sts/current>. In
order for the policy to be valid, the HTTP response body served at
this resource MUST exactly match the policy initially loaded via
the DNS TXT method, and MUST be served from an HTTPS endpoint at
the domain matching that of the recipient domain. (As this RFC
progress, the authors intend to register .well-known/smtp-sts.
See [RFC5785]. See _Future_ _Work_ for more information.)
o DNSSEC: In this mechanism, indicated by the "dnssec" value of the
"a" field, the sender MUST retrieve the policy via a DNSSEC signed
response for the _smtp_sts TXT record.
</quote>
As explained above, the "dnssec" mechanism makes little sense
for STS, "put all the wood behind one arrow". The example URI
needs to become the fixed well-known URI required with this
(STS) protocol. (I said as much to the authors at the M3AAWG
meeting in October).
Section 3.4. Policy Validation
<quote>
o Web PKI: When the "c" field is set to "webpki", the certificate
presented by the receiving MX MUST be valid for the MX name and
chain to a root CA that is trusted by the sending MTA. The
certificate MUST have a CN or SAN matching the MX hostname (as
described in [RFC6125]) and be non-expired.
o DANE TLSA: When the "c" field is set to "tlsa", the receiving MX
MUST be covered by a DANE TLSA record for the recipient domain,
and the presented certificate MUST be valid according to that
record (as described by [RFC7672]).
</quote>
Once again "tlsa" makes no sense. This goes away. The tricky
part is "root CA that is trusted by the sending MTA". The
problem with this is explained above, and also in section 1.3.4
of RFC7672. Therefore, while STS will work fairly well for
sending email to the large providers represented by the authors
of the draft, scaling it to the majority of domains will prove
challenging. This need not prevent progress on this draft,
however it is something worth noting.
Section 3.5. Policy Application
<quote>
o Report-only: In this mode, sending MTAs merely send a report to
the designated report address indicating policy application
failures. This can be done "offline", i.e. based on the MTA logs,
and is thus a suitable low-risk option for MTAs who wish to
enhance transparency of TLS tampering without making complicated
changes to production mail-handling infrastructure.
</quote>
While DANE does not (and likely should not) support report-only,
failure reporting is useful, and if STS domains publish reporting
addresses, DANE senders should be able to obtain these and use
use them. In particular it should be possible to publish just
a reporting address, without publishing the rest of the STS
policy. This would enable domains that use private-label
certificates to publish reporting addresses for DANE sending
systems.
This may mean that perhaps the reporting address, being not
especially security-sensitive, should be its own separate DNS
record after all, making it entirely neutral and separate from
STS.
I'll stop here for now, because the above is a substantial overhaul
of the draft, and the rest substantially depends on reaching closure
on the above observations. We have some work ahead of us to make
STS a lean-mean fighting machine (that just happens to complement
DANE in a small but useful way with the addition of reporting
addresses).
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
