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

[Chris Newman <[e-mail]>]

On March 24, 2016 at 2:16:27 , Mark Risher ([e-mail]) 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



--
Mark E. Risher |	 Group Product Manager |	 [e-mail] |	 650-253-3123

On Thu, Mar 24, 2016 at 1:45 AM, Daniel Margolis <[e-mail]> 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 <[e-mail]> 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.

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.

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.

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

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

On March 21, 2016 at 20:11:06 , Daniel Margolis ([e-mail]) 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. 

Thanks again for the feedback. 

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

> On 22 Mar 2016, at 08:49, Viktor Dukhovni <[e-mail]> wrote:
>
> On Tue, Mar 22, 2016 at 08:58:25AM +0100, Daniel Margolis wrote:
>
> 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.
>

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.

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

Neil


_______________________________________________
Uta mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/uta


_______________________________________________
Uta mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/uta


_______________________________________________
Uta mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/uta


_______________________________________________ 
Uta mailing list 
[e-mail] 
https://www.ietf.org/mailman/listinfo/uta