On 12.5.2014 22:42, Viktor Dukhovni wrote:
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.
I totally agree, some guidance how to use DANE in application-specific way
would be handy. An example from Kerberos world:
There is a Kerberos extension called PKINIT [RFC 4556] which relies on secure
CA certificate distribution. This CA cert is shared by the whole "Kerberos
realm". Maybe Kerberos protocol should be extended to look-up CA cert in DNS,
e.g. from
_kerberos.[REALM] IN TLSA ...
I'm sure there will be other cases like that.
(Note: I'm not saying that this particular case cannot be solved in other
ways, it is just an example.)
--
Petr Spacek @ Red Hat
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
