On Mon, May 12, 2014 at 02:32:05PM -0400, Olafur Gudmundsson wrote:
> Objective:
>
> ...
> DANE functionality to their work. In addition the working group
> will monitor and provide guidance to operators and tool developers.
> will monitor and provide guidance to operators and tool developers.
The above is a duplicate line.
> The DANE working group has developed a framework for securely
> retrieving keying information from the DNS [RFC6698]. This
> framework allows secure storing and looking up public key
> information in the DNS. This provides a binding between a domain
> name providing a particular service and the key that can be used
> to establish encrypted connection to that service.
[ The below thoughts are likely too specific to rise to visibility
in the charter, so are more likely fodder for 6698 revisions. ]
The RFC6698-specified lookup key of _<port>._<proto>.<fqdn> is not
universally applicable. It works OK for well known services such
as SMTP on ports 25/587 or HTTPS on 443, but is not always well
suited to environments in which service ports are dynamically
registered. Also, sometimes the verifier wants to authenticate a
TLS client acting on behalf of some domain in an appropriate
capacity.
Applications will in some use-cases need to agree on a lookup key
that is not tied to a numeric port. It could be a service name or
a client role. While a generic DANE TLS RFC (e.g. 6698) cannot
anticipate or standardize such alternative lookup keys, a future
update to 6698 should I think mention the need for such bindings,
and encourage applications employing DANE TLSA to define appropriate
alternative lookup keys. This could be of immediate benefit in
XMPP to authenticate the origin of inbound traffic.
It may also be reasonable to encourage applications to choose either
PKIX-TA/PKIX-EE or DANE-TA/DANE-EE whichever is more appropriate
to the problem at hand. Mixing the two yields the union of the
interoperability problems and the intersection of the security
features.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
