Re: [Uta] Warren Kumari's Discuss on draft-ietf-uta-mta-sts-17: (with DISCUSS)

[[e-mail]]

> Put slightly differently, allowing TXT-based indirection can at best be as
> secure as the current design, and at worse introduce some unknown
> vulnerability (depending on DNS architecture for a zone, etc). So I think
> that's really the main reason we wanted to keep it fixed.

Given the ability to redirect, there's going to be a temptation to piggyback
the handing out of mta-sts policies on some existing web service. It's unlikely
that doing this will result in a security win.

> In all likelihood it does not introduce a vulnerability nor does it
> introduce operational issues for anyone, but, valid concerns about
> "reserved" (even if just by convention) names notwithstanding, I'd rather
> accept any operational risks that poses than take the risk of a
> vulnerability. So I think you and I are on the same page here.

Since what's reserved is a single URI, not the domain, a conflicting use of the
domain actually reduces to a service combination scenario similar to what
indirection can lead to.

However, I think the liklihood of a domain conflict is a hell of a lot smaller
than the liklihood of administrators over-optimizing things, so independent of
the possibiltiy of a vulnerability we're not seeing, not allowing indirection
seems to be the better operational approach.

> Anyway, in the short run, there *is* at least the .well-known registry to
> ensure the full URI is reserved; in the long run I thought I recalled
> someone was looking into a registry for "reserved" DNS names. (But from the
> perspective of STS, if someone else uses "mta-sts" for anything else, it
> doesn't really affect the operation of the system.)

Exactly. And I think we can safely ignore the possibility of there
being a URI conflict.

				Ned