>>>>> "Viktor" == Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> writes:
Viktor> You might wonder why I of all people should be making a fuss
Viktor> about using DNS for TLS security. After all, I'm
Viktor> co-authoring two DANE documents and described DANE as a
Viktor> candidate mechanism for opportunistic use of authentication
Viktor> in the Opportunistic Security [RFC7435] document.
Viktor> The reason is absolutely not that I am opposed to designs
Viktor> that employ and trust DNSSEC to enable TLS reference
Viktor> identifier indirection. I support the use of such designs.
Viktor> Rather, it seems that the URI draft glosses over the
Viktor> implementation details and implications much too casually.
Viktor> This is a major change from current practice, and I think
Viktor> should be acknowledged as such and explored in more detail.
I too support designs like this that use DNSSec to support TLS reference
identifier indirection as an approach that is appropriate for a
significant number of deployments.
So, I do think we should have standards in this space, but I think we
need to explore the implications of this major change.
I also want appropriate policy controls in place. This is great for
some deployments and would significantly reduce the security of other
deployments. So, in terms of policy, I'd want us to explore what sort
of policy we need to enable and also to find credible mechanisms for the
policy we decide we need. One of the simplest ways to apply policy is
to do so at the protocol/application level. For example we might decide
that mechanisms like the URI RR are appropriate when we're using large
trust anchor sets like the web PKI, but not when we're using application
or protocol-specific trust anchor sets.
That sort of policy is easy because you can codify it in standards
documents and implementations.
Where we decide that the policy is deployment specific, it it may get
much more complicated.
Still, I think we need to have at least the general version of that
discussion prior to putting a mechanism like this on the standards
track.
Earlier, I said that I thought it was premature to have a last-call on
this draft and Pete questioned me about that. What I mean is that I
think it is premature to approve this draft without an additional last
call. Even if we make minor textual changes, the implications are
significant enough that I think we should have a full re-review with a
better understanding of the security implications. I didn't get that
when I approached the existing last call.
I agree with Pete that drawing out this round of comments was very
useful.
I disagree that SRV or MX introduces similar complexity into standards.