On Mon, May 12, 2014 at 04:21:10PM -0400, Olafur Gudmundsson wrote:
> > 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.
>
> This also works well for services looked up via SRV records.
> As the SRV contains the port number.
> For a protocol that has some kind of other selector of port,
> still at the end of the day the "Server" side has a "known-port"
> to the client, if the service moves from one port to another port OR
> provides service on multiple ports then it is possible that the
> protocol definition for the DANE variant of that protocol can say
> lookup of Authentication records is <Proto>FP at hostname.
I am mostly pointing out that port is not universally the right
choice. Sometimes a service name or other identifier is more
appropriate, whether this is the case, or what might be a better
lookup key is application dependent.
One immediate conclusion is that TLS + DANE toolkits (OpenSSL,
GnuTLS, NSS) must not hard-code the mapping from (host, port) to
the corresponding TLSA RRset. There need to be multiple ways to
get a DANE TLSA authenticated connection, with the application able
to perform the TLSA lookup outside the library, or able to pass-in
a custom lookup domain and TLSA base domain...
> > 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.
>
> Interesting are you you are saying we want to examine/specify
> client side DANE records (right now DANE is all about server side records).
Yes, but we likely can't specify the lookup keys in an application
neutral manner. Rather we can discuss the problem generally, and
allow individual application protocols to construct appropriate
keys. Still there could be some guidance on how to apply DANE to
TLS client identity (when the client identity can be mapped to a
suitable name in DNS).
> > 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.
>
> Are you proposing a BCP?
>
> We can add that to the milestones, after the current Operational/Errata
> document is done.
Yeah, something like that, or merge this into the ops draft.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
