On Wed, Feb 25, 2015 at 05:28:35PM +0100, Patrik F?ltstr?m wrote:
> > Victor is correct. This draft introduces indirection through DNS.
> > Typically in the past when we've done indirection through DNS, we've not
> > changed the expected security principal that we're targeting.
> > It's that change that significantly changes the security model.
>
> It is not new with this draft and URI, it is done for example with SRV, and also MX.
DNS redirection indeed has precedents in MX and SRV records.
However, there is little to no prior practice in combining such
rediction with "strict" TLS wherein the client's reference identifier
for the server "chases" the redirection.
I am sure that some MTA implementations just blindly apply TLS
verification to the insecurely obtained MX hostname, even without
DNSSEC. Such "going through the motions" is not in my view a real
precedent. [ IIRC there was, and perhaps still is, a large email
filtering provider that verifies the name the server returns in
the clear in the first line of the EHLO response! This too is not
a precedent for the proposed URI security model. ]
> That said, it is an important discussion to have, and I have
> waited for the DNS and Applications Community to talk about it.
You might wonder why I of all people should be making a fuss about
using DNS for TLS security. After all, I'm co-authoring two DANE
documents and described DANE as a candidate mechanism for opportunistic
use of authentication in the Opportunistic Security [RFC7435]
document.
The reason is absolutely not that I am opposed to designs that
employ and trust DNSSEC to enable TLS reference identifier indirection.
I support the use of such designs. Rather, it seems that the URI
draft glosses over the implementation details and implications much
too casually. This is a major change from current practice, and
I think should be acknowledged as such and explored in more detail.
Some considerations relevant to combining DNSSEC-validated redirection
(which updates the client's notion of what to expect in peer
certificates) appear in:
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-14#section-1.3
I should note that MTA-to-MTA SMTP is a specific opportunistic TLS
application with a long history of deployment, so the above reference
is about that singular use-case in which the issues are relatively
well understood.
With URIs, it is far less clear what applications are in scope,
and what their security requirements might be. So a proper discussion
of DNS-based URI redirection might need to be described as a set
of considerations to apply when determining which schemes in the
URI to accept, when to "chase" the reference identifier to the
URI's target and even whether the DANE PKI might then be more
appropriate in some situations,
--
Viktor.