Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery?

[Nathaniel McCallum <[e-mail]>]

On Tue, 2016-05-17 at 22:26 +0200, Rick van Rein wrote:
> Hi,
> 
> I agree mostly with Jeffrey, but have some additional remarks /
> thoughts.
> 
> > _kerberos.REALM
> > 
> > is not a valid DNS URI record name. To translate the URI
> > 
> Yes, the RFC wants it to be of the form _server._transport, however
> 
> > https://host[:port][path]
> > 
> > to an URI record requires
> > 
> > _kerberos._https.host
> 
> where is _https defined as a transport?  RFC 7553 gives examples with
> _http._tcp -- I've always wondered to deal with _https and especially
> how to add semantics on top of it, so I certainly like the scheme,
> but
> is this format defined anywhere?  For SRV, I though transports were
> limited to TCP, UDP, SCTP -- so not even TLS, let alone HTTPS?
> 
> Nathaniel, I think what you are actually trying to do is to describe
> HTTPS as a tunneling technique, right?  Since this type of tunnel is
> designed to participate in the rope-pulling contest between
> application
> desires and (perhaps misguided) firewall configurations, it might be
> expected that new tunnels would be topped on as time passes.

Yes, this is possible: new tunnels may appear over time.

> Clients
> would need to keep up, but keep the older solutions working as
> well.  So
> instead, I would rather have some sort of a redirection to a somewhat
> general tunnel descriptor as a general discovery outcome when looking
> for a "direct" service description.  This would service many
> applications in the same manner.

How does the "general tunnel descriptor" help in the case of Kerberos
tunnelling where the tunnel protocols are Kerberos-specific?

The desire for abstraction here just adds complexity without any
benefit of reusability. OTOH, new Kerberos tunnelling protocols can
just get new URIs. In fact, this is already explicitly allowable in the
existing draft. So the system, as defined is perfectly flexible to new
situations in the future.

One advantage to the URI approach is that weights and priorities can be
used to appropriately transition between transports; something that is
not currently possible.