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

From: Mark Risher <[email-masked]>
Date: Sat, 19 Mar 2016 11:20:23 +0100

Dear UTA:
We have just submitted a proposal entitled SMTP Strict Transport Security,
which details a mechanism for protecting MTA-to-MTA email traffic against
TLS downgrade attacks and interception.

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.

Thank you for your consideration
/m

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 22 Mar 2016 06:35:27 +0000

> feedback and suggestions from the broader group and look forward to your

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-masked]" 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.

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 22 Mar 2016 08:58:25 +0100

Hi Viktor,

Thanks for all the thoughtful comments. I'll respond to what (at a glance)
seems to be the most significant three first.

>     might need to send email to.

This is of course a big topic, but I don't think we should assume that in
common deployment web browsers *do* rely upon a user to make some sound
human decision about whether to trust a CA. For example, here's the
multi-stage process to get Chrome to accept an untrusted certificate:
https://docs.oracle.com/cd/E24628_01/install.121/e39876/img/scrnshot_advanced.gif.
It's not insignificant to me that Oracle felt the need to document this
process for the users with screenshots: we *don't* expect the common
browser user to make a personal determination of what CAs to accept, so the
"background process" argument is, I think, based on a false premise.

In truth, we expect browser users to defer to their platform vendors to
make sane decisions for them, and we expect the owners of large websites to
be able to pick a CA that is widely trusted. With the rise of Let's Encrypt
and other free CAs, this doesn't seem overly burdensome.

>     this field is both onerous and superfluous.

There are two differences with the MX records here:

1. A (most likely) longer TTL on the STS policy versus the MX record
2. The option for wildcard's or broader patterns than merely a list of
valid hosts

This permits the publishing domain to declare that "for the next year, I
plan to always host my mail at example.com" without publishing specific MX
records that have a 1-year TTL (which of course could be brittle).

>     1-bit encoding is likely better.

I also dislike the copying of the policy into two places, for the reasons
Dave noted here:
https://mailarchive.ietf.org/arch/msg/ietf-smtp/nqWeUTe03mxJLltC-wHOsVvfbKo
.

The only real reason to do this is to allow MTAs to cheaply see if the
policy has been updated. This seems like a silly thing, since in normal
usage they never need to check as long as they have a cached policy, but
it's exactly that asymmetry that worries me: Since in normal usage the
traffic to the HTTPS endpoint will be minuscule compared to the SMTP
traffic to the domain, hosts are likely to dramatically underprovision the
former versus the latter. Unfortunately, then, in the case of a validation
*failure*, the HTTPS endpoint would (absent some other policy TTL separate,
and shorter from, the expiration lifetime) be bombarded with an HTTP GET
*once* *per* email.

So all we're really doing here (in the webpki case) is leveraging DNS as a
sort of caching layer. An alternative solution would be what I hinted at
above: to simply embed a short "TTL" in the policy. Or to say we don't care
and encourage the use of HEAD.

If we are willing to force the webpki validation method (as you assumed, I
think, above) and don't mind making senders handle this short-term TTL
logic,  I think we could make the publishing process simpler, with the
advantage Dave noted in the above-linked thread (i.e. an easier deployment
for customers of hosted mail services).

I'm somewhat on the fence about this trade-off myself, but I don't think
it's unreasonable. Thoughts?

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 22 Mar 2016 08:49:00 +0000

On Tue, Mar 22, 2016 at 08:58:25AM +0100, Daniel Margolis wrote:

> >     SMTP is not [so] much that obtaining and deploying CA certs is
> This is of course a big topic, ...

I don't think this is central to my feedback, more of an observation
on the framing of comparisons with DANE.  For the large providers,
the choice of CA of a popular-enough will be easy enough.  For
everyone else, DV certs from the long-tail of CAs will provide the
appearance of security (first a CA you've never heard of makes a
leap-of-faith assertion via insecure email to admin@domain, then
everyone trusts assertions from that CA).  Yes this model makes
some opportunistic MiTM more difficult, but at the cost of making
all domains comparably insecure.

I would urge the large providers to use a substantially more
restrictive set of CAs for email delivery within the "walled garden".
You might even publish that list of CAs as the only ones to trust
for sending email to the 800lb-gorilla email services.

This does make some domains more equal than others, but I think
that the scope of this effort is primarily to secure email between
and to same said providers, with all the other domains a lower
priority.  If you like, an extension of EMiG ("Email Made in Germany"
for those not familiar with that precedent) to a larger more
international group of providers.

This said, I don't want the discussion to focus on this specific
issue, let's put it aside for now, we can return to it later once
the important protocol bits are sorted out.

> 2. The option for wildcards or broader patterns than merely a list of
> valid hosts
>

Yes, that's why the MX record patterns should be in the STS policy
published at the HTTPS URL (JSON encoded), but there's no reason
to put it in DNS.  As I said, the DNS record can basically be
compressed to a 1-bit value, but see below...

> I also dislike the copying of the policy into two places, ...
> 
> policy has been updated.

For that, the DNS record should, instead of a single absent/present
bit, consist of a short (DNS) TTL "nonce" that is also published
in the JSON policy obtained at the HTTPS well-known URL.  Then
invalidation of the policy is cheaply achieved by updating the
nonce in DNS and in the HTTPS data.  Clients that have a cached
policy can quickly check the DNS nonce, and refresh via HTTPS when
the DNS nonce no longer matches the cached value.

There is no need to duplicate any of the semantic payload of the
record in DNS given that it stored and authenticated via HTTPS.

> sort of caching layer.

My (strong) suggestion: use DNS for just cache invalidation, and
perhaps also publication (via a separate record) of the "rua"
reporting URI.  Do not duplicate data which one must in any case
obtain and cache via HTTPS in DNS.

Do not attempt to hedge your bets and support DANE/DNSSEC via STS,
I don't think that makes much sense either.

> think, above)

Yes, force webpki in STS, it dramatically simplifies the DNS part
of the protocol, losslessly to around zero bits (ok an expiration
nonce), and also simplifies the HTTPS payload to fewer/simpler JSON
fields.

> it's unreasonable. Thoughts?

For hosting indirection, the customer domain still needs operate
a HTTPS well-known URI to avoid a variety of attacks.  They could
return a redirect from that server, or just cache and "proxy" the
payload from the provider's corresponding URL).  A once an hour
cron job to (securely) scrape the provider's data and re-publish
locally would be quite sufficient and keep everything simple.

Support for redirects would introduce substantial complexity for
the client, especially if allowed to nest...

Who should failure notifications go to?

In summary:

    * Radically simplify the DNS STS record to contain zero policy.

    * Consider publishing the "rua" separately in DNS, or else
      exclusively via the well-known URI.

    * Allow (DANE or other) domains to publish just the RUA,
      the feature is not STS-specific.

    * Drop all "pretense" of supporting DANE/DNSSEC via STS policy,
      this is not needed.

With that, we can then polish the draft's exposition, security
considerations, reporting format, ...

-- 
	Viktor.

P.S.  (Off topic for this thread, private email feedback welcome
if any of the large providers are interested in pursuing this
further):

I'm still looking forward to some of the large providers supporting
DANE outbound, no need to sign your own zones for that.  You just
need validating resolvers that can handle the lookup volume and a
TLS stack that can do DANE verification.  Perhaps BoringSSL will
at some point import the DANE bits from OpenSSL 1.1.0...

If OpenSSL is already the TLS library, then DANE TLSA validation
will soon be a built-in feature, but the MTA still needs to obtain
the TLSA records and provide them to the OpenSSL library.

---

From: Neil Cook <[email-masked]>
Date: Tue, 22 Mar 2016 09:21:38 +0000

> On 22 Mar 2016, at 08:49, Viktor Dukhovni <[email-masked]> wrote:
> 

I agree with the “don’t hedge your bets” part. I was quite surprised to see all the justification for STS in the first part of the document, including “the mechanism described here presents a variant for systems not yet supporting DNSSEC”, and yet then goes on to include DNSSEC as one of the policy authentication mechanisms.

>      the feature is not STS-specific.
+1

Neil

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 22 Mar 2016 11:10:57 +0100

Thanks for the feedback to both of you. I don't disagree; I think Viktor
makes a very solid point in favor of simplicity. In addition, a report-only
protocol could be extended to support arbitrary error reporting; an
out-of-band (e.g. HTTP) channel to share delivery failures between domains
strikes me as useful in the general case.

Separately, because we're already assuming providers (both sending and
receiving) make a choice on implementing DANE and/or webPKI, I don't think
actually splitting the two makes it any more or less complex to implement,
or should discourage adoption of one or the other mechanism.

So I would say I'm feeling a bit in favor of Viktor's suggestion, but I'd
like to chat a bit more with my co-authors and think about it first. ;)

Viktor, as an aside regarding the hosted mail scenario, we already had the
suggestion to move the HTTPS endpoint to something like "_
smtp_sts.example.com/current". If we do that, the customer (example.com)
can make this a CNAME for "_smtp_sts.hostingdomain.com", who can use SNI to
serve the policy with the customer's cert (assuming the customer trusts the
hosting provider with this; for domains that don't operate their own HTTPS
endpoint this seems to me to be likely). For the more complex case, the
cron setup you describe doesn't seem too onerous, I agree.

Thanks again for the feedback.

On Tue, Mar 22, 2016 at 10:21 AM, Neil Cook <[email-masked]> wrote:

> I agree with the “don’t hedge your bets” part. I was quite surprised to
> see all the justification for STS in the first part of the document,
> including “the mechanism described here presents a variant for systems not
> yet supporting DNSSEC”, and yet then goes on to include DNSSEC as one of
> the policy authentication mechanisms.
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 22 Mar 2016 16:09:33 +0000

> like to chat a bit more with my co-authors and think about it first. ;)

Great.  One more question.  I see that there are parallel
non-overlapping threads on this proposal on tha UTA and IETF-SMTP
lists.  Is either the "primary" forum for discussing this proposal?
Should people be encouraged to cross-post?  Should the IETF-SMTP
users who want to discuss it be encouraged to shift the discussion
here?

> cron setup you describe doesn't seem too onerous, I agree.

Prepending a fixed sub-domain label is fine as an extra bit of rope
to support various forms of indirection.

-- 
	Viktor.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 Mar 2016 16:10:02 +0000

Hi Viktor,

> users who want to discuss it be encouraged to shift the discussion
I think so, this document is within the UTA charter (or at least very 
close to it).

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 22 Mar 2016 17:13:23 +0100

Yeah, we posted this to SMTP in order to get extra eyes on this, but we're
new at this process, so bear with us. I think we should have said, "Hey,
this is on the UTA mailing list, please head over there to discuss." I'll
post a followup to that effect now. :)

---

From: Chris Newman <[email-masked]>
Date: Wed, 23 Mar 2016 20:44:46 -0700

This document is providing STS functionality for SMTP relay, while DEEP is providing STS functionality for SMTP submission (plus IMAP & POP). I believe it’s important to align these two proposals and am open to changing DEEP to do so (https://tools.ietf.org/html/draft-ietf-uta-email-deep-04).

Note that early versions of DEEP also provided STS for SMTP relay but solving the STS problem for MUAs is sufficiently difficult and different that I think it’s good to have a separate document for SMTP relay STS. If you are open to editing this as a WG document with rough consensus changes, I would welcome the collaboration.

I agree with most of Viktor’s comments so I won’t repeat them. Here are some new comments:

1. I personally dislike using DNS records for any of this proposal. I believe SMTP security policy is best communicated within SMTP as this minimizes attack surface, eliminates the need for TOFU in some scenarios, and puts the policy configuration closer to the server operator. We can use the PKIX trust model with SMTP/STARTTLS just as we use it with HTTPS (with Viktor’s notable caveats) so HTTPS is not needed and shouldn’t be used to validate SMTP security policy.

2. I think using HTTPS to validate MX records in the non-DNSSEC scenario is a very interesting idea. But MX records are routing rather than policy and thus don’t belong in a policy record. How about just defining a well-known HTTPS URL that contains a copy of the actual binary MX record for the domain (or a semantically-identical syntax transformation of that binary record)? Then we just need the SMTP server to advertise the binary policy flag Viktor mentioned to get a non-DNSSEC model to reasonably trustworthy MX records.

3. DEEP goes through a lot of trouble to create an extensible framework for policy by creating a registry (while still keeping the model simple). Your proposal notes the need for future policy work but lacks a model to add new policies. I think the SMTP STS document is incomplete without an extensibility model and you can get it by referencing DEEP (and if we need to change the syntax or model in DEEP to make that more palatable, I’m open to that discussion).

4. UTA already discussed the idea of timeouts for security policy in DEEP and reached rough consensus not to include timeouts. I doubt the SMTP relay use case is sufficiently different to alter that rough consensus. So I suspect we can drop timeouts from SMTP STS after a discussion, but if there is rough consensus to keep timeouts in SMTP STS then I’d like to reconsider that decision for DEEP on a proposal-alignment basis.

5. DEEP’s reporting mechanism for SMTP submission (the CLIENT command) is an as-it-happens rather than after-the-fact mechanism. I’d like to investigate the idea of an after-the-fact mechanism for MUAs although I’m not sure it’s a good fit. Regardless, we need to use the same reporting syntax for submission SMTP and relay SMTP, so I’m open to changing DEEP’s current submission reporting syntax as needed to align them.

6. I think JSON would be a better format than XML for reporting. The reports are coming from an untrusted source and will be parsed. JSON has a much smaller attack surface than XML and as this is part of a security mechanism, I think that’s an important consideration. The one potential advantage I see to XML is the wide availability of SAX-style parsers that can handle large volumes of data, but I think the attack surface argument should win in this case. I know a number of XML parser libraries are insecure-by-default due to schema URI resolution. Regardless, this is an interesting design trade-off for a rough consensus decision.

7. I think your document should reference DEEP section 6 so SMTP relay cipher usage is recorded for trace purposes; that’s another aspect of your transparency goal.

7. I note in passing that DEEP allows use of the PKIX trust model and the DANE trust model at the same time. I think that’s good.

I’m wondering if I should rename DEEP to MUA STS?

		- Chris

On March 21, 2016 at 20:11:06 , Daniel Margolis ([email-masked]) wrote:

Thanks for the feedback to both of you. I don't disagree; I think Viktor makes a very solid point in favor of simplicity. In addition, a report-only protocol could be extended to support arbitrary error reporting; an out-of-band (e.g. HTTP) channel to share delivery failures between domains strikes me as useful in the general case. 

Separately, because we're already assuming providers (both sending and receiving) make a choice on implementing DANE and/or webPKI, I don't think actually splitting the two makes it any more or less complex to implement, or should discourage adoption of one or the other mechanism. 

So I would say I'm feeling a bit in favor of Viktor's suggestion, but I'd like to chat a bit more with my co-authors and think about it first. ;) 

Viktor, as an aside regarding the hosted mail scenario, we already had the suggestion to move the HTTPS endpoint to something like "_smtp_sts.example.com/current". If we do that, the customer (example.com) can make this a CNAME for "_smtp_sts.hostingdomain.com", who can use SNI to serve the policy with the customer's cert (assuming the customer trusts the hosting provider with this; for domains that don't operate their own HTTPS endpoint this seems to me to be likely). For the more complex case, the cron setup you describe doesn't seem too onerous, I agree. 

+1

Neil

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 24 Mar 2016 09:45:34 +0100

Hey,

Of course we reviewed DEEP during the drafting process, but as you say, the
targets are slightly different. I've responded to some individual points
inline; in summary, though, I think you raise some actionable points about
using the DEEP policy framework (which I will read up on), changing the
reporting syntax, and recording cipher usage. I have questions for you
below on some of the other points.

Thanks.

On Thu, Mar 24, 2016 at 4:44 AM, Chris Newman <[email-masked]>
wrote:

> This document is providing STS functionality for SMTP relay, while DEEP is
> providing STS functionality for SMTP submission (plus IMAP & POP). I
> believe it’s important to align these two proposals and am open to changing
> DEEP to do so (https://tools.ietf.org/html/draft-ietf-uta-email-deep-04).
>

Agreed that there's some overlap. One rather obvious observation, to frame
the discussion, though, is that DEEP addresses a case where clients connect
to relatively few *novel* servers (you rarely configure a new IMAP or SMTP
MSA server) and have user-facing UIs, so some of the challenges around
discovering and remembering policies and handling failures are a bit
different. But we should certainly try to align the proposals nonetheless.

> Note that early versions of DEEP also provided STS for SMTP relay but
> solving the STS problem for MUAs is sufficiently difficult and different
> that I think it’s good to have a separate document for SMTP relay STS. If
> you are open to editing this as a WG document with rough consensus changes,
> I would welcome the collaboration.
>
> 1. I personally dislike using DNS records for any of this proposal. I
> believe SMTP security policy is best communicated within SMTP as this
> minimizes attack surface, eliminates the need for TOFU in some scenarios,
> and puts the policy configuration closer to the server operator. We can use
> the PKIX trust model with SMTP/STARTTLS just as we use it with HTTPS (with
> Viktor’s notable caveats) so HTTPS is not needed and shouldn’t be used to
> validate SMTP security policy.
>

If I read correctly, you're making two different comments here:

a. We should communicate the STS policies within SMTP, not using DNS.
b. We should authenticate the STS policies directly using the SMTP-TLS
server certificate, not some HTTPS side-channel. (Of course this follows
from (a), for the most part.)

Those are spot-on comments. We had initially proposed solely extending SMTP
for policy exchange, similarly to Jim's proposal in "REQUIRETLS" but in
reverse (https://tools.ietf.org/html/draft-fenton-smtp-require-tls-01).
However, for our proposed semantics (i.e. "always require TLS for my domain
in the future, unless I give you a signed change of policy"), this is
tricky in a very specific case: if changing the policy requires serving a
new signed policy, and serving policies is done via SMTP, then users of
hosted mail services who turn on "require TLS" will be unable to revoke
their published policy if they move to a hosted provider who doesn't
support the protocol to begin with.

(It also means these domains' SMTP servers will have to support SNI and
serve a server certificate that actually matches the recipient domain,
whereas the current mechanism allows one to run a separate HTTPS server
with client.com's cert but to "bless" SMTP connections to mailhost.com's
cert.)

So as far as I can see, to satisfy this scenario, the policy exchange
*must* be some out-of-band protocol. HTTPS is purely a choice of
convenience; I had originally proposed signed blobs stuck in DNS RR, but
big resource records seem problematic in practice (even if the RFC supports
them) and the whole thing gets ugly fast.

Can you think of a way to handle the hosted scenario with SMTP, or some
other more elegant solution?

> 2. I think using HTTPS to validate MX records in the non-DNSSEC scenario
> is a very interesting idea. But MX records are routing rather than policy
> and thus don’t belong in a policy record. How about just defining a
> well-known HTTPS URL that contains a copy of the actual binary MX record
> for the domain (or a semantically-identical syntax transformation of that
> binary record)? Then we just need the SMTP server to advertise the binary
> policy flag Viktor mentioned to get a non-DNSSEC model to reasonably
> trustworthy MX records.
>

I think this is mostly pending the discussion for #1: if we need DNS for
the reason outlined above, it's convenient to use it for this, too. If we
don't, of course, it may not be.

> 3. DEEP goes through a lot of trouble to create an extensible framework
> for policy by creating a registry (while still keeping the model simple).
> Your proposal notes the need for future policy work but lacks a model to
> add new policies. I think the SMTP STS document is incomplete without an
> extensibility model and you can get it by referencing DEEP (and if we need
> to change the syntax or model in DEEP to make that more palatable, I’m open
> to that discussion).
>

I will have to reread this part of your proposal more closely, but unifying
the policy framework certainly sounds reasonable on its face.

> 4. UTA already discussed the idea of timeouts for security policy in DEEP
> and reached rough consensus not to include timeouts. I doubt the SMTP relay
> use case is sufficiently different to alter that rough consensus. So I
> suspect we can drop timeouts from SMTP STS after a discussion, but if there
> is rough consensus to keep timeouts in SMTP STS then I’d like to reconsider
> that decision for DEEP on a proposal-alignment basis.
>

Is there a particular mail thread I should read to get the context here?
Sorry...

> 5. DEEP’s reporting mechanism for SMTP submission (the CLIENT command) is
> an as-it-happens rather than after-the-fact mechanism. I’d like to
> investigate the idea of an after-the-fact mechanism for MUAs although I’m
> not sure it’s a good fit. Regardless, we need to use the same reporting
> syntax for submission SMTP and relay SMTP, so I’m open to changing DEEP’s
> current submission reporting syntax as needed to align them.
>
> 6. I think JSON would be a better format than XML for reporting. The
> reports are coming from an untrusted source and will be parsed. JSON has a
> much smaller attack surface than XML and as this is part of a security
> mechanism, I think that’s an important consideration. The one potential
> advantage I see to XML is the wide availability of SAX-style parsers that
> can handle large volumes of data, but I think the attack surface argument
> should win in this case. I know a number of XML parser libraries are
> insecure-by-default due to schema URI resolution. Regardless, this is an
> interesting design trade-off for a rough consensus decision.
>

No strong feeling here on my end. XML is in theory convenient because it
supports XSD; in practice I think the XSD I wrote in the draft has some
bugs. ;) Using JSON is also quite reasonable, and *feels* like a natural
choice if we want to support reporting via HTTP/S POST as well, which we
may.

> 7. I think your document should reference DEEP section 6 so SMTP relay
> cipher usage is recorded for trace purposes; that’s another aspect of your
> transparency goal.
>

Thanks, makes sense.

>
> 7. I note in passing that DEEP allows use of the PKIX trust model and the
> DANE trust model at the same time. I think that’s good.
>

DEEP is a pretty cool acronym, but yeah, STS has this dis/advantage of
referencing a mostly known item (HSTS). Insofar as I was trying to hew as
closely to the HSTS trust model as possible (within the confines of the
protocol) I think that's a helpful analogy. But probably not the biggest
point right now. ;)

> can make this a CNAME for "_smtp_sts.hostingdomain.com", who can use SNI
> to serve the policy with the customer's cert (assuming the customer trusts
> the hosting provider with this; for domains that don't operate their own
> HTTPS endpoint this seems to me to be likely). For the more complex case,
> the cron setup you describe doesn't seem too onerous, I agree.
>

---

From: Mark Risher <[email-masked]>
Date: Thu, 24 Mar 2016 09:07:44 -0700

Hi, Chris:
Thanks for the comments.

> and puts the policy configuration closer to the server operator.

In addition to the possible difficulty in migrating a domain off of a
server (particularly in a multi-tenant config), we also felt that
introducing a new SMTP verb might be dramatically more complicated than
deploying in parallel, because at least the DNS/webpki reporting can be
added offline without changes to the core MTA.

Was that not a concern in DEEP? Or simply unavoidable?

/m

--
Mark E. Risher |  Group Product Manager |  [email-masked] |  650-253-3123

On Thu, Mar 24, 2016 at 1:45 AM, Daniel Margolis <[email-masked]>
wrote:

> Hey,
>
> Of course we reviewed DEEP during the drafting process, but as you say,
> the targets are slightly different. I've responded to some individual
> points inline; in summary, though, I think you raise some actionable points
> about using the DEEP policy framework (which I will read up on), changing
> the reporting syntax, and recording cipher usage. I have questions for you
>> This document is providing STS functionality for SMTP relay, while DEEP
>> is providing STS functionality for SMTP submission (plus IMAP & POP). I
> Those are spot-on comments. We had initially proposed solely extending
> SMTP for policy exchange, similarly to Jim's proposal in "REQUIRETLS" but
> in reverse (https://tools.ietf.org/html/draft-fenton-smtp-require-tls-01).
> I will have to reread this part of your proposal more closely, but
> unifying the policy framework certainly sounds reasonable on its face.
>
>
>> Viktor, as an aside regarding the hosted mail scenario, we already had
>> the suggestion to move the HTTPS endpoint to something like "_

---

From: Chris Newman <[email-masked]>
Date: Fri, 25 Mar 2016 14:28:54 -0700

On March 23, 2016 at 18:45:45 , Daniel Margolis ([email-masked]) wrote:
Hey, 

Of course we reviewed DEEP during the drafting process, but as you say, the targets are slightly different. I've responded to some individual points inline; in summary, though, I think you raise some actionable points about using the DEEP policy framework (which I will read up on), changing the reporting syntax, and recording cipher usage. I have questions for you below on some of the other points.

Thanks.

On Thu, Mar 24, 2016 at 4:44 AM, Chris Newman <[email-masked]> wrote:
This document is providing STS functionality for SMTP relay, while DEEP is providing STS functionality for SMTP submission (plus IMAP & POP). I believe it’s important to align these two proposals and am open to changing DEEP to do so (https://tools.ietf.org/html/draft-ietf-uta-email-deep-04).

Agreed that there's some overlap. One rather obvious observation, to frame the discussion, though, is that DEEP addresses a case where clients connect to relatively few *novel* servers (you rarely configure a new IMAP or SMTP MSA server) and have user-facing UIs, so some of the challenges around discovering and remembering policies and handling failures are a bit different. But we should certainly try to align the proposals nonetheless.

a. We should communicate the STS policies within SMTP, not using DNS.
b. We should authenticate the STS policies directly using the SMTP-TLS server certificate, not some HTTPS side-channel. (Of course this follows from (a), for the most part.) 

Those are spot-on comments. We had initially proposed solely extending SMTP for policy exchange, similarly to Jim's proposal in "REQUIRETLS" but in reverse (https://tools.ietf.org/html/draft-fenton-smtp-require-tls-01). However, for our proposed semantics (i.e. "always require TLS for my domain in the future, unless I give you a signed change of policy"), this is tricky in a very specific case: if changing the policy requires serving a new signed policy, and serving policies is done via SMTP, then users of hosted mail services who turn on "require TLS" will be unable to revoke their published policy if they move to a hosted provider who doesn't support the protocol to begin with.
The discussion around whether to include a timeout in DEEP was basically to ask the question: Should a domain that makes a commitment to be secure be allowed to revoke that commitment? The rough consensus in the face-to-face meeting was that the answer to that question should be “no”. That is, once the domain makes the commitment to a certain level of security, they’ll have to only use hosting providers that offer the same or better security. Isn’t that a good thing if we’re trying to make the Internet more secure?

(It also means these domains' SMTP servers will have to support SNI and serve a server certificate that actually matches the recipient domain, whereas the current mechanism allows one to run a separate HTTPS server with client.com's cert but to "bless" SMTP connections to mailhost.com's cert.)
That doesn’t follow if there is a mechanism to get trustworthy routing information (specifically, signed MX records).

So as far as I can see, to satisfy this scenario, the policy exchange *must* be some out-of-band protocol. HTTPS is purely a choice of convenience; I had originally proposed signed blobs stuck in DNS RR, but big resource records seem problematic in practice (even if the RFC supports them) and the whole thing gets ugly fast.

Can you think of a way to handle the hosted scenario with SMTP, or some other more elegant solution?
I believe using HTTPS as an alternative to DNSSEC to bless the MX routing information makes sense; IMHO it’s a significant good idea in your draft (obviously using DNSSEC to sign the MX record is a better security model, but an HTTPS well-known URI model is presently more deployable at many domains). But I see no reason to use HTTPS to bless SMTP policy; that seems like a semantic mismatch to me.

I think this is mostly pending the discussion for #1: if we need DNS for the reason outlined above, it's convenient to use it for this, too. If we don't, of course, it may not be.

I will have to reread this part of your proposal more closely, but unifying the policy framework certainly sounds reasonable on its face. 

Is there a particular mail thread I should read to get the context here? Sorry...
It should be in the minutes for the Prague IETF UTA meeting last summer.

No strong feeling here on my end. XML is in theory convenient because it supports XSD; in practice I think the XSD I wrote in the draft has some bugs. ;) Using JSON is also quite reasonable, and *feels* like a natural choice if we want to support reporting via HTTP/S POST as well, which we may.
The XML schema parsers I’ve used produce such poor error reports that I find XSD only useful to provide a binary valid/not-valid result. It’s also difficult to write XSD with a correct extensibility model. For a reporting syntax this simple, I think a prose description and examples are going to be more useful to an implementer than XSD. My feelings on this issue are not so strong that I’d try to block a rough consensus to use XML, but I think the security issues are significant enough that the syntax debate is needed.

Thanks, makes sense. 

DEEP is a pretty cool acronym, but yeah, STS has this dis/advantage of referencing a mostly known item (HSTS). Insofar as I was trying to hew as closely to the HSTS trust model as possible (within the confines of the protocol) I think that's a helpful analogy. But probably not the biggest point right now. ;) 

- Chris

+1

Neil

---

From: Mark Risher <[email-masked]>
Date: Fri, 25 Mar 2016 15:15:04 -0700

>
> The discussion around whether to include a timeout in DEEP was basically
> to ask the question: Should a domain that makes a commitment to be secure
> be allowed to revoke that commitment? The rough consensus in the
> face-to-face meeting was that the answer to that question should be “no”.
> That is, once the domain makes the commitment to a certain level of
> security, they’ll have to only use hosting providers that offer the same or
> better security. Isn’t that a good thing if we’re trying to make the
> Internet more secure?

I agree philosophically that we should strive to be ever-increasing in
security. What some of the authors worried about was, at least in early
days when there is spotty deployment, would fear of "lock-in" act as a
deterrent. It's theoretical and hard to measure what would happen in
practice. Sounds like the "hmmm" consensus was that it's worth the risk?

If we're not worried about lock-in, then we could remove a lot of
complexity. Any empirical studies people can point to?

The XML schema parsers I’ve used produce such poor error reports that I
> find XSD only useful to provide a binary valid/not-valid result.

There's pretty universal consensus that nobody likes the XML we started
with. I've got this one flagged for the face-to-face meeting; ideally we
would leverage an existing reporting (JSON) format, but there seem to be
myriad options but none with more than modest adoption. Any suggestions?

Thanks for the comments,
/m

On Fri, Mar 25, 2016 at 2:28 PM, Chris Newman <[email-masked]>
wrote:

> The discussion around whether to include a timeout in DEEP was basically
> to ask the question: Should a domain that makes a commitment to be secure
> be allowed to revoke that commitment? The rough consensus in the
> face-to-face meeting was that the answer to that question should be “no”.
> That is, once the domain makes the commitment to a certain level of
> security, they’ll have to only use hosting providers that offer the same or
> better security. Isn’t that a good thing if we’re trying to make the
> Internet more secure?
>
> whereas the current mechanism allows one to run a separate HTTPS server with
>  client.com's cert but to "bless" SMTP connections to mailhost.com's
> cert.)
>
> That doesn’t follow if there is a mechanism to get trustworthy routing
> information (specifically, signed MX records).
>
> I believe using HTTPS as an alternative to DNSSEC to bless the MX routing
> information makes sense; IMHO it’s a significant good idea in your draft
> (obviously using DNSSEC to sign the MX record is a better security model,
> but an HTTPS well-known URI model is presently more deployable at many
> domains). But I see no reason to use HTTPS to bless SMTP policy; that seems
> like a semantic mismatch to me.
>
> The XML schema parsers I’ve used produce such poor error reports that I
> find XSD only useful to provide a binary valid/not-valid result. It’s also
> difficult to write XSD with a correct extensibility model. For a reporting
> syntax this simple, I think a prose description and examples are going to
> be more useful to an implementer than XSD. My feelings on this issue are
> not so strong that I’d try to block a rough consensus to use XML, but I
> think the security issues are significant enough that the syntax debate is
> needed.
>

---

From: Chris Newman <[email-masked]>
Date: Fri, 25 Mar 2016 15:32:08 -0700

On March 24, 2016 at 2:16:27 , Mark Risher ([email-masked]) wrote:
Hi, Chris:
Thanks for the comments.
 
1. I personally dislike using DNS records for any of this proposal. I believe SMTP security policy is best communicated within SMTP as this minimizes attack surface, eliminates the need for TOFU in some scenarios, and puts the policy configuration closer to the server operator. 
In addition to the possible difficulty in migrating a domain off of a server (particularly in a multi-tenant config), we also felt that introducing a new SMTP verb might be dramatically more complicated than deploying in parallel, because at least the DNS/webpki reporting can be added offline without changes to the core MTA.
The SMTP-policy in DNS model allows advertising receiver policy without changing the MTA, but it still requires a core MTA upgrade to the sender before it actually improves security for the domain. Most MTA software includes both receiver and sender in the same package, so sites do need to upgrade their core MTA package to get better security. I don’t think it’s a good idea for a site to have receiver and sender software of different product versions deployed (except during a transition period). So I see no actual deployment benefit for the SMTP policy negotiation by putting it in DNS.

 Was that not a concern in DEEP? Or simply unavoidable?
Both, plus I’m not a fan of adding new unnecessary protocol traffic. Having the negotiation added to the existing SMTP EHLO negotiation doesn’t add new packets to the core mail transfer operation as the DNS-policy approach does.

I may be biased as a email server developer, but it seems much easier to add protocol extensions at the application layer than to change performance-critical lower level connection logic and DNS lookups (often deeply buried in badly designed APIs). In addition, the application protocols tend to have good error reporting mechanisms (human readable strings) which are not present in DNS or other layers so it’s going to be easier to get an application-layer solution working in practice.

Now for the SMTP relay scenario, decoupling the reporting mechanism from the core MTA makes a lot of sense to me. It may also make sense for IMAP/POP/Submission, but I need to think about that some more as there are subtle deployment tradeoffs.

		- Chris

/m

On Thu, Mar 24, 2016 at 1:45 AM, Daniel Margolis <[email-masked]> wrote:
Hey, 

Thanks.

 

 

 

 

Thanks, makes sense. 

- Chris

+1

Neil

---

From: Chris Newman <[email-masked]>
Date: Fri, 25 Mar 2016 17:00:38 -0700

On March 25, 2016 at 15:15:22 , Mark Risher ([email-masked]) wrote:
The discussion around whether to include a timeout in DEEP was basically to ask the question: Should a domain that makes a commitment to be secure be allowed to revoke that commitment? The rough consensus in the face-to-face meeting was that the answer to that question should be “no”. That is, once the domain makes the commitment to a certain level of security, they’ll have to only use hosting providers that offer the same or better security. Isn’t that a good thing if we’re trying to make the Internet more secure?

I agree philosophically that we should strive to be ever-increasing in security. What some of the authors worried about was, at least in early days when there is spotty deployment, would fear of "lock-in" act as a deterrent. It's theoretical and hard to measure what would happen in practice. Sounds like the "hmmm" consensus was that it's worth the risk?

If we're not worried about lock-in, then we could remove a lot of complexity. Any empirical studies people can point to?

The XML schema parsers I’ve used produce such poor error reports that I find XSD only useful to provide a binary valid/not-valid result. 

There's pretty universal consensus that nobody likes the XML we started with. I've got this one flagged for the face-to-face meeting; ideally we would leverage an existing reporting (JSON) format, but there seem to be myriad options but none with more than modest adoption. Any suggestions?
While I have implemented the leading extensible syntaxes (XML & JSON), I don’t have much experience with reporting formats. What I do know is that generalizing a data model too broadly has a tendency to make the models sufficiently complex that they’re harder to deploy and less useful. So unless there’s a clearly winning generalized reporting model I don’t know about, I’d try to focus on “SMTP TLS security policy error reporting” or “SMTP/MUA TLS security policy error reporting” and resist generalizing the format further than that. Beyond that, the two concerns I have with a reporting data model are having the syntax and semantics of the fields defined with reasonable clarity/precision and having enough extensibility in the model so an incompatible version change is unlikely to happen in the future as things are added.

		- Chris

Thanks for the comments,
/m

On Fri, Mar 25, 2016 at 2:28 PM, Chris Newman <[email-masked]> wrote:
On March 23, 2016 at 18:45:45 , Daniel Margolis ([email-masked]) wrote:
Hey, 

Thanks.

 

 

Thanks, makes sense. 

- Chris

+1

Neil

---

From: Mark Risher <[email-masked]>
Date: Fri, 25 Mar 2016 17:45:04 -0700

>
> it still requires a core MTA upgrade to the sender before it actually
> improves security for the domain...So I see no actual deployment benefit
> for the SMTP policy negotiation by putting it in DNS.

This is where we might differ. I feel that even the reporting mode – making
any TLS MITM very visible – does have benefit, and in our prototype
deployment we have already found actionable intelligence through offline
reporting based on existing logs. There is value to "try before you buy"
but I totally grok the added complexity of adding more protocols to the
mix. We heard similar feedback from Viktor (of Postfix) about the
undesirability of "teaching Postfix to speak HTTPS."

Will add this to the discussion topics. Thanks, Chris!

/m

On Fri, Mar 25, 2016 at 5:00 PM, Chris Newman <[email-masked]>
wrote:

> While I have implemented the leading extensible syntaxes (XML & JSON), I
> don’t have much experience with reporting formats. What I do know is that
> generalizing a data model too broadly has a tendency to make the models
> sufficiently complex that they’re harder to deploy and less useful. So
> unless there’s a clearly winning generalized reporting model I don’t know
> about, I’d try to focus on “SMTP TLS security policy error reporting” or
> “SMTP/MUA TLS security policy error reporting” and resist generalizing the
> format further than that. Beyond that, the two concerns I have with a
> reporting data model are having the syntax and semantics of the fields
> defined with reasonable clarity/precision and having enough extensibility
> in the model so an incompatible version change is unlikely to happen in the
> future as things are added.
>
> - Chris
>
> Thanks for the comments,
> /m
>
>
>
> --
>> Agreed that there's some overlap. One rather obvious observation, to
>> frame the discussion, though, is that DEEP addresses a case where clients
>> connect to relatively few *novel* servers (you rarely configure a new IMAP
>> or SMTP MSA server) and have user-facing UIs, so some of the challenges
>> around discovering and remembering policies and handling failures are a bit
>>> 4. UTA already discussed the idea of timeouts for security policy in
>>> DEEP and reached rough consensus not to include timeouts. I doubt the SMTP
>>> relay use case is sufficiently different to alter that rough consensus. So
>>> I suspect we can drop timeouts from SMTP STS after a discussion, but if
>>> there is rough consensus to keep timeouts in SMTP STS then I’d like to
>>> reconsider that decision for DEEP on a proposal-alignment basis.
>>>
>>
>>> 7. I note in passing that DEEP allows use of the PKIX trust model and
>>> the DANE trust model at the same time. I think that’s good.
>>>
>>> So I would say I'm feeling a bit in favor of Viktor's suggestion, but
>>> I'd like to chat a bit more with my co-authors and think about it first. ;)
>>>
>>> can make this a CNAME for "_smtp_sts.hostingdomain.com", who can use
>>> SNI to serve the policy with the customer's cert (assuming the customer
>>> trusts the hosting provider with this; for domains that don't operate their
>>> own HTTPS endpoint this seems to me to be likely). For the more complex
>>> case, the cron setup you describe doesn't seem too onerous, I agree.
>>>

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 26 Mar 2016 13:35:41 +0000

Speaking of reporting specifically:

On 26 Mar 2016, at 00:45, Mark Risher <[email-masked]> wrote:

>> it still requires a core MTA upgrade to the sender before it actually improves security for the domain...So I see no actual deployment benefit for the SMTP policy negotiation by putting it in DNS.
> 
> This is where we might differ. I feel that even the reporting mode – making any TLS MITM very visible – does have benefit, and in our prototype deployment we have already found actionable intelligence through offline reporting based on existing logs.

A way to report TLS failures is valuable.

In addition to XML versa JSON, there are other reporting mechanisms like ARF (see RFC 6650, for example) which seems applicable to this.

I am quite concern about yet another reporting mechanism, which is different from other 3 (maybe more) already defined mechanisms.

---

From: "John Levine" <[email-masked]>
Date: 26 Mar 2016 19:55:01 -0000

>In addition to XML versa JSON, there are other reporting mechanisms like ARF (see RFC 6650, for example) which seems applicable to this.

ARF is about messages, this is about connections.

>I am quite concern about yet another reporting mechanism, which is different from other 3 (maybe more) already defined mechanisms.

This is the same reporting mechanism that DMARC uses.  I can say from
experience that reporting is one part of DMARC that works great.

I have about 87,000 aggregate DMARC reports and 57,000 individual
failure reports, summarized in a database from which I should try
to extract something interesting someday.

DMARC uses XML, these days it'd make more sense to use json but in
doesn't make that much difference since there are parsing libararie
for both.

R's,
John

---

From: Daniel Margolis <[email-masked]>
Date: Sun, 27 Mar 2016 10:11:58 +0200

> better security. Isn’t that a good thing if we’re trying to make the

Well, to be clear, the issue of expirations is mostly moot as long as
domains can revoke a policy out-of-band even if the MTA doesn't know about
STS. That's why everything is DNS/HTTPS-based. But that's the other point
of discussion in this thread, so to refocus it a bit, I think we can assert
that to support the migrate-to-a-non-STS-host scenario, we need to have at
least expirations or out-of-band revocation, if not both.

I would love to drive adoption insofar as I want to push mail security. But
do I want to do something that locks in our users or makes SMTP less
portable? Definitely not. To me, that prospect is not a worthwhile exchange.

> like a semantic mismatch to me.

I'm not sure I understand your suggestion. You're saying that the HTTPS
resource should say what MX hosts/SANs are OK, but the MTA itself should
say whether it will always support TLS? Or am I misunderstanding?

---

From: Daniel Margolis <[email-masked]>
Date: Sun, 27 Mar 2016 10:16:15 +0200

Yeah, as you can see, we basically cribbed from DMARC for the reporting
format. But I'm more than happy to switch to JSON.

I looked at ARF, but I think it's a bit hard to use it for this; if I
remember right, ARF is only key/value pair, which makes it harder to do
things like

hostname: [list of failures]

or other complicated structures.

Anyway, I think this is mostly cosmetic, but I agree with Alexey's point
about a proliferation of reporting formats. Maybe we can use HPKP's JSON
format, or something else. Suggestions more than welcome.

Dan

On Sat, Mar 26, 2016 at 8:55 PM, John Levine <[email-masked]> wrote:

> >In addition to XML versa JSON, there are other reporting mechanisms like
> ARF (see RFC 6650, for example) which seems applicable to this.
>
> >I am quite concern about yet another reporting mechanism, which is
> different from other 3 (maybe more) already defined mechanisms.
>