On Tue, May 15, 2018 at 3:30 PM Daniel Margolis <dmargo...@google.com>
> 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.
> 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.
> 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.)
Yup, there is no current registry for "reserved" DNS names -- there is a
registry for reserved Special Use Domain Names (
Locally Served DNS Zones (
and Dave Crocker is working on a registry for underscore names (
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/) -- we
don't have a registry for "reserved" DNS names, and that is the root of my
concern - if we did, we could just toss this in, and we'd be golden --
instead, we have names which are used *by convention* --- I've been
noodling on text to explain that "by convention the name is at
mat-sts.example.com", but I haven't been able to come up with text that
doesn't sound contrived at best, or disingenuous at worst.
> On Mon, May 14, 2018 at 7:54 PM Viktor Dukhovni <ietf-d...@dukhovni.org>
>> > On May 14, 2018, at 1:41 PM, Daniel Margolis <dmargo...@google.com>
>> > I don't understand either of these comments.
>> > The TXT record could only safely be used to select the host (i.e. the
in-zone name) for the policy URL, not the fully qualified domain, so I
don't think it introduces the weakness Viktor supposes.
>> Yes, I was well aware that the name would have to share a suffix with the
>> policy domain. And yet, there is still a problem if there are any names
>> in policy the domain that are controlled by customers, rather than the
>> organization. I don't think that an insecurely vended policy authority
>> within the policy domain) is a good idea.
>> Uta mailing list
> Uta mailing list
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
Uta mailing list