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.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
