Subject: [DNSOP] Prefixed name spaces and DANE client TLSA

From: "John Levine" <[email-masked]>
Date: 13 Jan 2016 05:55:05 -0000

I'm having what seems to me a very peculiar argument over in DANE.

There's a draft called draft-huque-dane-client-cert-02 about
validating SSL certificates for client hosts.  The idea, which seems
reasonable, is that if an SMTP or other client presents a TLS
certificate claiming that it's outbound.example.com, the server it's
talking to can look up a TLSA record to see if the certificate is
valid, analogously to the way a client looks up the server's TLSA.

What's peculiar is the names.  The previous proposal was to look up a
TLSA at _smtp.outbound.example.com, then somone noted that _smtp is
for servers, so they want to look up the newly invented name
_smtp-client.outbound.example.com.  If you have a client for some
other service, you make up a name.  (Read the draft if this seems like
an implausible summary.)

I suggested they could avoid a lot of future name collision pain by
registering "client" as a pseudo_service name, and then looking up
_smtp._client._tcp.outbound.example.com.  If your client is using
another service, you use the service's name from the existing registry
of services instead of _smtp, e.g., _imaps._client.tcp.myhost.example.

The DANE crowd thinks this is a terrible idea, it's too complicated,
makes the SRV-ID verification harder, name collisions won't happen
and/or are easily solved.  Am I missing something, or are they?

Signed,
Confused

---

From: George Michaelson <[email-masked]>
Date: Wed, 13 Jan 2016 16:59:33 +1000

I think the mapping of SMTP (a protocol, an over-the wire framing and
dialogue about exchanging mail) has been crossed (crossing-the-beam
crossed) with a ROLE. a client can be an SMTP speaker, and a
forwarder/delivery agent can be an SMTP speaker. They aren't performing the
sale role.

So does DANE want to identify the ROLE being performed or the protocol
being used to do it? How would DANE feel if instead of SMTP it said
DECNet-Mail?

The sub-domain thing, is that a real zone-cut? Are there detectable zone
boundaries? Or is this mapping dot-separated elements but without implying
a zone-cut?

-G

On Wed, Jan 13, 2016 at 3:55 PM, John Levine <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Shane Kerr <[email-masked]>
Date: Wed, 13 Jan 2016 09:51:47 +0100

George,

I think you are correct in highlighting the role vs. protocol
difference.

Looking at it like that, John's idea makes sense, although probably it
should be inverted, so:

_client._smtp._tcp.outbound.example.com 

This way case, it will happily support protocols that are not
client/server (for example, one with more roles).

It's not clear to me that this is actually cleaner than:

_smtp-client._tcp.outbound.example.com

Although it somehow feels better because the dots nicely separate the
semantics encoded in the name.

On the DNS side, I don't think any of the proposed solutions would
be better or worse than any other. I don't think any are particularly
complicated, or make verification more difficult. But it wouldn't be
the first time that people argue for a particular approach to
a protocol because it was the first thing they thought of. ;)

Cheers,

--
Shane

At 2016-01-13 16:59:33 +1000

---

From: Tony Finch <[email-masked]>
Date: Wed, 13 Jan 2016 10:24:31 +0000

> other service, you make up a name.  (Read the draft if this seems like

This naming scheme is a bad idea because it looks very similar to XMPP SRV
records but has confusingly different semantics.

_xmpp-client refers to an XMPP server endpoint for use by clients.
_xmpp-server refers to an XMPP server endpoint for use by other servers.

_submission refers to SMTP-like server endpoints for use by clients.
_smtp-client is proposed to refer to SMTP client initiators.

More generally this promises to clutter up the service identifier
namespace with identifiers for clients, which are not services.

I like the idea of taking the server's service labels and prefixing
them with _client.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Thames, Dover, Wight: Northwest backing southwest 5 to 7, perhaps gale 8
later. Moderate or rough. Showers, becoming thundery later. Good, occasionally
poor later.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 13 Jan 2016 09:30:01 -0500

> > other service, you make up a name.  (Read the draft if this seems like

Yes, folks, please read the draft and also the thread on DANE.

(And Shane - it wasn't the "first thing we though of" - in fact all
alternate
suggestions brought up in the thread had already be considered by the
authors of the draft.)

> _xmpp-server refers to an XMPP server endpoint for use by other servers.

Yeah, this was discussed on DANE already, where I said the following:

    Yeah, I'm aware of that. I think the XMPP community made an
    unfortunate choice in those names  - I might have suggested
    "_xmpp-c2s" and "_xmpp-s2s" instead.

There is no established or standardized convention for client service names
in the IANA registry yet. Are we doomed to avoid "-client" just because of
the (unstandardized) precedent set by one application?

> namespace with identifiers for clients, which are not services.

Yet the IANA registry seems to have a provision for registering
client service names (i.e. application specific identifiers used by
clients). So, the cluttering is already there. Perhaps there is a need
to create a separate registry.

As for cluttering up the namespace in a DNS zone and causing
collisions (John Levine's contention), I don't buy it. These application
labels
are organized underneath "client-specific" domain names - this does not
meet my definition of cluttering. All labels descending at that point
pertain
to the specific client, and usages for colliding labels are disambiguated
by the resource record type.

> them with _client.

Actually, that was one my original proposals outlined in -00 of the draft.
It was taken out after deliberations with my co-authors, but I do see a
rationale for it.

Here's the original draft:

    https://tools.ietf.org/html/draft-huque-dane-client-cert-00

The current draft is:

    https://tools.ietf.org/html/draft-huque-dane-client-cert-02

I am fine with reintroducing the "_client" label (and I believe Viktor is
too)
_if_ there is consensus for it. The service label then can rid itself of the
"-client" suffix, assuming IANA service registry folks do not raise
objections.
I can look into that.

The -00 draft did also contain an alternate suggestion that included
the transport label. I am far less convinced this is needed. Client
identities are not expected to be transport specific for the same
application,
so this introduces an unnecessary complication, and we should I think
be conservative in how much application semantics we encode into
domain names.

-- 
Shumon Huque

---

From: "John R Levine" <[email-masked]>
Date: 13 Jan 2016 12:12:21 -0500

> clients).

It might seem that way if we didn't look too closely.  All of the service 
names that contain words like "client" have reserved port numbers so they 
are in fact services.  For example port 5222, xmpp-client, is for 
client-to server xmpp connections as opposed to port 5269, xmpp-server, 
for server-to-server connections.  See RFC 6120.

> As for cluttering up the namespace in a DNS zone and causing collisions 
> (John Levine's contention), I don't buy it. These application labels are 
> organized underneath "client-specific" domain names - this does not meet 
> my definition of cluttering. ...

It's cluttering up the namespace of prefixed names.  I am a lazy guy, I 
see that the set of protocols used by clients is by definition exactly the 
same set of protocols used by servers, and we already have a registry for 
those.  So rather than spending time and effort inventing a new name every 
time I want to publish a cert for a client of another service, I'm going 
to invent one rule that solves the client naming problem forever:

We reserve the single pseudo-service name "client", and the client label 
that corresponds to any service label _foo is _foo._client.  All done.

> Actually, that was one my original proposals outlined in -00 of the draft.

That was close, but you got the names backward.

Here's a concrete example.  My laptop is named mypc.example.com. Because I 
am a forward thinking guy, I send a DANE-verified client cert whenever I 
connect for submission, POP, IMAP, or jabber, and because I'm still lazy, 
I use the same certificate for all of them.  The DNS records to tell the 
world about that are:

  $ORIGIN mypc.example.com
  _submission._client._tcp IN TLSA ... cert stuff ...
  _imap._client._tcp       IN CNAME _submission._client._tcp
  _imaps._client._tcp      IN CNAME _submission._client._tcp
  _pop3._client._tcp       IN CNAME _submission._client._tcp
  _pop3s._client._tcp      IN CNAME _submission._client._tcp
  _xmpp-client._client._tcp IN CNAME _submission._client._tcp

How would you do it?

R's,
John

---

From: Ray Bellis <[email-masked]>
Date: Wed, 13 Jan 2016 17:22:45 +0000

On 13/01/2016 17:12, John R Levine wrote:

> Here's a concrete example.  My laptop is named mypc.example.com. Because
> I am a forward thinking guy, I send a DANE-verified client cert whenever
> I connect for submission, POP, IMAP, or jabber, and because I'm still
> lazy, I use the same certificate for all of them.  The DNS records to
> tell the world about that are:
> 
>  $ORIGIN mypc.example.com

Personally, I wouldn't use those owner names, as that's inconsistent
with _tcp being associated with SRV usage, with the previous label being
one from the IANA port registry.

I quite like the idea of _client._<service>._<proto>, though.

Thinking more though, I actually prefer _<service>._<proto>._client.

The use of _client on the right-hand side would allow this to fit in
Dave Crocker's "underscore registry" as the "most significant label",
with everything to the left of that borrowed from SRV.

Ray

---

From: "John Levine" <[email-masked]>
Date: 13 Jan 2016 20:01:45 -0000

>one from the IANA port registry.

See RFC 6698, which already uses _tcp to name TLSA server records.
This tries to minimize the extra creativity.

In case it wasn't clear, I was proposing to put "client" into the
port/service registry (same thing), as a pseudo-service.

>with everything to the left of that borrowed from SRV.

I suppose, but doing it as _<service>._client._<proto> puts it in the
existing service namespace.  It's not a huge difference, and it's been
clear for a while that if we do Dave's registry, part of what it
includes will be a list of the underscore names that are protocol
labels. That currently includes _tcp _udp _sip _xmpp _ldap _http _ocsp
so I suppose adding one more isn't awful, but it seems needlessly
kludgy.

R's,
John

---

From: Ray Bellis <[email-masked]>
Date: Wed, 13 Jan 2016 20:05:46 +0000

On 13/01/2016 20:01, John Levine wrote:
> I suppose, but doing it as _<service>._client._<proto> puts it in  > the existing service namespace. It's not a huge difference, and it's 
 > been clear for a while that if we do Dave's registry, part of what > 
it includes will be a list of the underscore names that are protocol > 
labels. That currently includes _tcp _udp _sip _xmpp _ldap _http > _ocsp 
so I suppose adding one more isn't awful, but it seems > needlessly kludgy.

When Dave and I last discussed that draft in any detail (back in 
Orlando!) my proposal was that it should for SRV-based services the only 
entries should be _tcp and _udp (or other L3 protocols), and that 
anything that exists in the IANA port registry (with the prepended 
underscore) would be a legal label to the left of that.

That would completely get away from the need to maintain the likes of 
_sip, etc in the underscore registry.

Ray

---

From: "John Levine" <[email-masked]>
Date: 13 Jan 2016 20:09:31 -0000

>underscore) would be a legal label to the left of that.

I think we're in violent agreement -- that's why I want to put _client
into the service registry so it doesn't further mess up the list of L3
protocols.

R's,
John

---

From: Ray Bellis <[email-masked]>
Date: Wed, 13 Jan 2016 20:14:42 +0000

> into the service registry so it doesn't further mess up the list of L3
Right, except that I want that service registry to only include the 
most-significant-label.

Yes, there's then a recursive situation in my proposed order where the 
stuff to the left of that also then potentially comes out of the service 
registry.   To me, though, that's preferable from having the _client 
label separate the existing _<service> and _<proto> labels that SRV uses.

Ray

---

From: Shumon Huque <[email-masked]>
Date: Wed, 13 Jan 2016 15:22:31 -0500

On Wed, Jan 13, 2016 at 3:05 PM, Ray Bellis <[email-masked]> wrote:

>> I suppose, but doing it as _<service>._client._<proto> puts it in  > the
>> existing service namespace. It's not a huge difference, and it's
>>
> > been clear for a while that if we do Dave's registry, part of what > it
> includes will be a list of the underscore names that are protocol > labels.
> That currently includes _tcp _udp _sip _xmpp _ldap _http > _ocsp so I
> suppose adding one more isn't awful, but it seems > needlessly kludgy.
>
> When Dave and I last discussed that draft in any detail (back in Orlando!)
> my proposal was that it should for SRV-based services the only entries
> should be _tcp and _udp (or other L3 protocols), and that anything that
> exists in the IANA port registry (with the prepended underscore) would be a
> legal label to the left of that.
>

Is Dave's registry proposal documented in written form anywhere? Some
planned alignment with that (assuming it has consensus) seems like a good
idea.

-- 
Shumon Huque

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 13 Jan 2016 15:25:05 -0500

On 1/13/16 3:22 PM, Shumon Huque wrote:
> On Wed, Jan 13, 2016 at 3:05 PM, Ray Bellis <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>         I suppose, but doing it as _<service>._client._<proto> puts it
>         in  > the existing service namespace. It's not a huge
>         difference, and it's
>
>     > been clear for a while that if we do Dave's registry, part of what > it includes will be a list of the underscore names that are protocol > labels. That currently includes _tcp _udp _sip _xmpp _ldap _http > _ocsp so I suppose adding one more isn't awful, but it seems > needlessly kludgy.
>
>     Orlando!) my proposal was that it should for SRV-based services the
>     only entries should be _tcp and _udp (or other L3 protocols), and
>     that anything that exists in the IANA port registry (with the
>     prepended underscore) would be a legal label to the left of that.
>
>     That would completely get away from the need to maintain the likes
>     of _sip, etc in the underscore registry.
>
>
> planned alignment with that (assuming it has consensus) seems like a
> good idea.
>
> --
> Shumon Huque

You mean this?

https://datatracker.ietf.org/doc/draft-crocker-dns-attrleaf/

---

From: "John R Levine" <[email-masked]>
Date: 13 Jan 2016 15:49:22 -0500

> Right, except that I want that service registry to only include the 

Um, right, a client label is _<service>._client._<proto>

> Yes, there's then a recursive situation in my proposed order where the stuff 
> to the left of that also then potentially comes out of the service registry. 
> To me, though, that's preferable from having the _client label separate the 
> existing _<service> and _<proto> labels that SRV uses.

Don't understand why.  These aren't SRV labels, they're TLSA labels, and 
TLSA labels already use _<proto> labels differently than SRV does, in RFC 
6698.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "John R Levine" <[email-masked]>
Date: 13 Jan 2016 15:50:46 -0500

> planned alignment with that (assuming it has consensus) seems like a good

It's draft-crocker-dns-attrleaf-07.

I've been pinging Dave about working on it but haven't heard back.

Regards,

---

From: Shane Kerr <[email-masked]>
Date: Thu, 14 Jan 2016 15:21:45 +0100

Shumon,

At 2016-01-13 09:30:01 -0500
> suggestions brought up in the thread had already be considered by the

I apologize for my mis-characterization. I was both ignorant and unkind,
things that I dislike in others and hate in myself. :(

Cheers,

--
Shane

---

From: Rob Austein <[email-masked]>
Date: Thu, 14 Jan 2016 14:25:01 -0500

[Commenting only on technical aspect of the name structure --
discussion of whether the namespace is cluttered, pretty, intuitive,
etc, are too abstract for me.  Not making light of user confusion
issues, just recusing on them.]

I would recommend that you think about how any of these proposed
schemes interact with DNS wildcards.  Yes, some people use wildcards
with TLSA RRs, or even with CNAME RRs pointing to TLSA RRs: this
allows one to express "every service on machine foo.example.org uses
the same certificate" concisely.

So if one buys George's analysis of this as a role vs protocol
distinction, the question becomes whether it's more useful to be able
to group by roles or by protocols.  That is, are you more likely to
want to say "all roles for protocol foo use the same certificate",
"all protocols for role foo use the same certificate", or just not
allow any kind of grouping here at all.  The first of these makes the
most sense to me, YMMV.

Wildcards are probably also the main technical reason for caring about
differences between the naming for TLSA and SRV RRs.

---

From: "John Levine" <[email-masked]>
Date: 15 Jan 2016 01:24:11 -0000

>the same certificate" concisely.

That is an excellent point.  While you're at it, it'd also be a good
idea to consider how it interacts with DNAMEs.

For example, if you use my naming convention with the protocols, you
can use DNAMEs to say the client certs for all the protocols are the
same, e.g.:

	_client._udp.myhost.example DNAME _client._tcp.myhost.example
	_client._sctp.myhost.example DNAME _client._tcp.myhost.example

This doesn't let you alias server certs without also aliasing client
certs, no idae if that would be a problem in practice.  The comments
in RFC 6698 suggest that aliasing server certs is rarely useful.

R's,
John

---

From: Shumon Huque <[email-masked]>
Date: Thu, 14 Jan 2016 21:58:14 -0500

> the same certificate" concisely.

Sure. For client credentials, the most natural use of wildcards I envision
would be to specify that a given client uses the same credentials for all
application protocols. In our proposed form, this can be accomplished
by replacing the leading _app label with a wildcard. Or by aliasing a
defined set of per-app names to a generic name.

> allow any kind of grouping here at all.  The first of these makes the

I assume here that role means a "client", "server" or other role for the
same application protocol.

We also need to define what protocol means - is it the application
protocol or the transport protocol? If considering both independently,
we have additional possible groupings.

But yes, I agree that making it easy to group the commonly expected
ways should be a goal. Assuming the base domain name will be the
same in each grouping, "all protocols for role foo" should be expressible
with wildcards. "All roles for application protocol Foo" is a bit more
challenging, since the client TLSA record uses a symbolic name for the
application whereas the server TLSA record uses a port number. Assumptions
could be made about applications using well known ports I guess, but
that doesn't offer a complete solution.

-- 
Shumon Huque

---

From: Shumon Huque <[email-masked]>
Date: Thu, 14 Jan 2016 22:35:47 -0500

> in RFC 6698 suggest that aliasing server certs is rarely useful.

Just on the last point, I couldn't find where in 6698 it says that about
aliases, but RFC 7671 offers two design patterns involving aliases
for server TLSA records that might be common - one for virtual hosting,
and another to alias many server records to a common DANE-TA
issuer. I've already seen quite a number of instances of the latter deployed
in the field.

-- 
Shumon Huque

---

From: "John R Levine" <[email-masked]>
Date: 14 Jan 2016 23:09:07 -0500

> aliases, ...

You're right, it doesn't, but it does say disparaging things about 
wildcards which have sort of the same issues.

> but RFC 7671 offers two design patterns involving aliases
> issuer.

I'd think DNAMEs would work great for that.  Publish one set of records 
describing the common issuer, then use a few DNAMEs to point everyone else 
at it, e.g. in the client case:

   $ORIGIN hostco.example
   _submission._client._tcp TLSA ... issuer info ...
   _pop3s._client._tcp CNAME _submission._client._tcp
   _pop3._client._tcp CNAME _submission._client._tcp
   _imaps._client._tcp CNAME _submission._client._tcp
   _imap._client._tcp CNAME _submission._client._tcp
   _xmpp-client._client._tcp CNAME _submission._client._tcp

then

   _client._tcp.bob.example. DNAME _client.tcp.hostco.example.
   _client._tcp.carol.example. DNAME _client.tcp.hostco.example.
   _client._tcp.ted.example. DNAME _client.tcp.hostco.example.
   _client._tcp.alice.example. DNAME _client.tcp.hostco.example.

This has the nice property of creating exactly the records you want, as 
opposed to wildcards which match everything whether or not it makes sense.

Regards,

---

From: Shane Kerr <[email-masked]>
Date: Fri, 15 Jan 2016 10:48:14 +0100

Ray,

At 2016-01-13 17:22:45 +0000

> with everything to the left of that borrowed from SRV.

I tried to mention it in my previous mail, but perhaps I wasn't clear
enough.

I think that if you are going to encode roles into the namespace, that
you should do it in a protocol-specific way.

For example, there are protocols that don't have client/server, but
rather master/slave relationships (a common setup in replication
scenarios). There may be protocols with more complex relationships; I
think that Kerberos or other token-passing protocols may fit in this
description. Distributed transaction systems may elect a coordinator,
and recording that in DNS may speed discovery. And so on...

This is why I think that if you encode _client behavior in a label, it
should be protocol-specific:

_client._fubar._tcp

That way you don't have to try to shoehorn master/slave and say "well,
a master is basically a server, if you don't think about it too
hard..." ;)

Cheers,

--
Shane

---

From: James Cloos <[email-masked]>
Date: Mon, 18 Jan 2016 14:10:13 -0500

>>>>> "RB" == Ray Bellis <[email-masked]> writes:

RB> I quite like the idea of _client._<service>._<proto>, though.

RB> Thinking more though, I actually prefer _<service>._<proto>._client.

I suggested _<service>._client. on the dane list.  Having _client on thr
left would impact having a CNAME RR at _<service>._<proto>.

There really is no need for _<proto>, and given that some higher-level
protocols work over multiple protos, having a single TLSA is easier than
having to have a bunch of CNAMEs.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: "John Levine" <[email-masked]>
Date: 22 Jan 2016 02:46:05 -0000

>having to have a bunch of CNAMEs.

Don't remember whether I responded to this, but in case I didn't, if
you want to make all of the _udp entries the same as _tcp, one DNAME
will do the trick.  I don't see this as a significant problem.

R's,
John