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

[Viktor Dukhovni <[e-mail]>]

On Wed, Jan 13, 2016 at 05:29:47AM -0000, John Levine wrote:

>  It has very little to do with distinct transport protocols, and
>  everything to do with avoiding name collisions.  Nobody runs POP or
>  IMAP over UDP, but the SRV names are still _pop3._tcp and _imap._tcp.

That's because SRV records are a generic (somewhat over-engineered)
construction, and we're stuck with separate:

	_kerberos._udp.realm.example. IN SRV 100 0 88 kdc1.example.
	_kerberos._tcp.realm.example. IN SRV 100 0 88 kdc1.example.

with the only benefit of this separation being the ability to
discover that a given realm has no UDP-based or has no TCP-based
KDCs.  None of this is especially relevant for clients.

So we can keep the client TLSA record query name simple with:

    ; TLSA RRtype sufficient to distinguish this from all
    ; other uses of the name, and any collisions with server
    ; names with look like _port._proto.server.example.
    ;
    _application.box.example. IN TLSA 3 1 1 ...

or we inject additional labels, making the name further removed
from identifying a DANE application at a given DNS node:

    _application._tcp._client._dane.box.example. IN TLSA 3 1 1 ...

because _client might be used in non-dane contexts, and we want to
distinguish TCP from UDP, ...  But what's the real benefit to all
this?  We're publishing TLSA records for "application" on "box.example",
is any  of the other baggage really helpful?

With enough such labels, we don't need a TLSA RRtype, just use TXT,
and encode the data in JSON.

    _application._tcp._client._tlsa._dane.box.example. IN TXT "{usage=3, selector=1, mtype=1, data=...}"

The point I'm trying to make is that given the base domain, an
application-specific initial _label, an the TLSA RRtype, we have
all the essential distinguishing identifiers and anything else is
baggage that needs justification.  

James makes a plausible point about _client as a way to carve out
a zone for clients, but because unlike SMIME/A or OPENPGPKEY the
base domain is here typically not a zone apex, but rather a specific
host, carving out a new zone under each host scales poorly.  And
this takes away the simplicity of an identity mapping between the
query domain and the corresponding SRV-ID.

So I while I am sympathetic to his argument, I don't think it holds
up in the end.

If we start injecting _proto, and various additional labels, I am
pretty we'd be overdoing the design.  There has be a good reason
for these, beyond superficial similarity to server use-cases that
are not actually analogous.

-- 
	Viktor.