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

[Mark Risher <[e-mail]>]

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.

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

/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
>
>