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

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
George Michaelson <ggm@algebras.org> wrote:

> 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 <johnl@taugh.com> wrote:
> 
> > 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
> >
> > _______________________________________________
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> >  