Apologies for the slow reply here. (I was on vacation.)
Ned: thanks for the clear summary. I'll start working on those issues.
Dave: thanks also for the direct feedback. To be honest, though, after all this discussion, I'm somewhat struggling to sort out what's actionable from what isn't, as I suspect you can understand. I'll try to read through and come up with a priority list of compatible changes, but I may miss things--if there are changes (to the text, versus the entire approach) which you want to call out as priorities, I would very much appreciate any help.
(Regarding the point about in-protocol vs HTTPS callouts, Viktor already addressed this thoroughly, but to restate somewhat differently, we operate with the following constraints: 1. we have to secure the domain, not the host (since securing only the host does not achieve anything even after first-contact in preventing downgrades) and 2. we want to allow authenticated migration off of an implementing service (i.e. to allow recipient domains to move from a hosting service that supports STS to one that does not, and to prove to implementing senders that that move is OK with them). The combination of those two constraints imply out-of-band policy exchange, I believe.)
On Thu, Apr 12, 2018 at 6:25 PM Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote:
On Thu, Apr 12, 2018 at 10:27:25AM +0100, Dave Cridland wrote:
> > Unfortunately, per-MTA rather than per-domain policy entirely loses all
> > protection against active attacks when the MX RRset is not secure.. The
> > MiTM just forges the MX RRset, yielding new hosts for which no policy
> > is stored.
>
> I can see I'm in the rough here, but I'm still unconvinced there's any real
> difference between forging the MX RRset or forging the TXT record.
Forging the TXT record is a downgrade attack (only) on *first*
contact. After a policy is cached and so long as it remains
unexpired and gets refreshed periodically, forging the TXT record
is no longer effective. Where-as, in the absence of DNSSEC, per-MX
policy is subject to MX RRset forgery for each and every delivery.
> > Time will tell. Either approach may yet fail to gain much traction.
> > So, yes, we can't assume that MTA-STS is transitional, that's mostly how
> > I like to think of it...
>
> I think the two are subtly incompatible at the moment in some cases, and
> the flow involved means sending MTAs need to find out the policy prior to
> connecting.
Since DANE is downgrade resistant, and more resistant to mis-issuance
than DV certs, and MTAs don't require or care about EV, when usable
DANE TLSA records are found for the receiving SMTP server ("MX
host"), a sending MTA that supports both should go with DANE, and
not do STS (subject to local policy). When no usable DANE TLSA
records are found, any STS policy in scope for the domain should
be used.
> > There will be all kinds of implementations, and all kinds of ways for
> > operators to mess up their deployment. Making it easier to not mess up has
> > a very high priority from my perspective. Overly brittle security gets
> > turned off.
>
> I agree; which is why I both suspect and hope these policy documents will
> be generated by the providers.
You keep assuming there's a third-party provider. Many domains
operate their own email servers, and these may have less sophisticated
operational practices. A fixed policy document is less fragile.
A domain owner can specify their reference identifiers by parent
domain if they so choose. For some this may be less prone to
operational tradeoff at a small trade-off in security. Recall that
STS is an optional upgrade from opportunistic unauthenticated
STARTTLS, and will only gain traction if operationally reliable.
I expect that STS adoption beyond the large providers will be slow,
and that making it a bit easier is worth it. Domains that don't
need the wildcard feature can specify all their MX hosts explicitly
in the policy.
> > https://www.openssl.org/docs/man1.1.0/ssl/SSL_set_hostflags.html
> > https://www.openssl.org/docs/man1.1.0/ssl/SSL_add1_host.html
>
> Well, I never knew that this API supported wildcard matching against
> wildcards.
>
> I still think this is wrong, but it's wrongness that's been implemented
> already so I'll assume it's too late to fix.
<off-topic, follow-ups off-list?>
IMHO there's nothing to fix, the use of sub-domain reference
identifiers is entirely optional. If the application provides
an explicit hostname to match (no leading ".") then it is
matched verbatim.
If an application *chooses* to ask OpenSSL to match a sub-domain,
".mail.example.com" or similar, then it is matched as documented
(what you call wildcard against wildcard). Most applications
don't and won't ask for sub-domain reference identifiers. An
application that implements STS over OpenSSL would ask for
those when that's what is in the STS policy.
</off-topic>
--
Viktor.
_______________________________________________
Uta mailing list
Uta@xxxxxxxx
https://www.ietf.org/mailman/listinfo/uta
<<attachment: smime.p7s>>
