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 | [email protected] | 650-253-3123 On Thu, Mar 24, 2016 at 1:45 AM, Daniel Margolis <[email protected]> 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 protected]> > 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 ([email protected]) >> 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 <[email protected]> >> wrote: >> >>> >>> > On 22 Mar 2016, at 08:49, Viktor Dukhovni <[email protected]> >>> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/uta >>> >>> >> _______________________________________________ >> Uta mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/uta >> >> > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta > >
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
