> 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
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
