Re: [dane] namespace management, DANE Client Authentication draft updated

[Viktor Dukhovni <[e-mail]>]

On Wed, Jan 13, 2016 at 04:32:35PM -0000, John Levine wrote:

> >RRtype is sufficient for collision avoidance, I don?t think we gain
> >any practical benefit by adding the other labels.
> 
> Oh, OK.  How about inventing a TLSACLIENT RRtype and use no prefix
> labels at all?
> 
> I don't think that's a very good idea, but I'd be interested to hear
> if other people agree, and if so, why.

Well, we still a service-specific prefix, because we're signalling
the public keys for clients of a particular service on a particular
network node.  Clients for different services may well have different
certs/keys.

The main argument that supports more than just a single service
prefix (if those are actually prone to collisions with various
other common prefixes like _spf, _dkim, ...) is that CNAMES are
quite useful with TLSA RRs when the payload is a trust-anchor digest
that should just be and managed in one place.

Thus if we really believe that there's a collision problem on just
the prefixed names, so that potential application client prefixes
(of the form suggested in the draft) already have existing non-TLSA
records, then it would be better to have just one additional label:

    _service._client.node.example. IN TLSA ...

So that one can create CNAME records:

    _service._client.node.example. IN CNAME _dane.example.

I still don't see any use for _tcp/_udp in there.

-- 
	Viktor.