Re: [Uta] New proposal: SMTP Strict Transport Security

[Viktor Dukhovni <[e-mail]>]

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:[e-mail]" 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.