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

[John Levine]

>There really is no need for _, 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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[James Cloos]

> "RB" == Ray Bellis  writes:

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

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

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

There really is no need for _, 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  OpenPGP: 0x997A9F17ED7DAEA6

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Shane Kerr]

Shumon,

At 2016-01-13 09:30:01 -0500
Shumon Huque  wrote:
> (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.)

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

Cheers,

--
Shane

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Shumon Huque]

On Thu, Jan 14, 2016 at 2:25 PM, Rob Austein  wrote:

>
> 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.
>

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.

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.
>

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John R Levine]

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.


Just on the last point, I couldn't find where in 6698 it says that about
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
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'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,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Rob Austein]

[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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Shane Kerr]

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  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  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
> >  

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tim Wicinski]

On 1/13/16 3:22 PM, Shumon Huque wrote:

On Wed, Jan 13, 2016 at 3:05 PM, Ray Bellis > wrote:



On 13/01/2016 20:01, John Levine wrote:

I suppose, but doing it as _._client._ 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.


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


You mean this?

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


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John R Levine]

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.
Right, except that I want that service registry to only include the 
most-significant-label.


Um, right, a client label is _._client._

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 _ and _ labels that SRV uses.


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


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Shumon Huque]

On Wed, Jan 13, 2016 at 3:05 PM, Ray Bellis  wrote:

>
>
> On 13/01/2016 20:01, John Levine wrote:
>
>> I suppose, but doing it as _._client._ 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.


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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John R Levine]

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


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

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

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

>> 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?
>
>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.

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.

>Thinking more though, I actually prefer _._._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.

I suppose, but doing it as _._client._ 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

>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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ray Bellis]

On 13/01/2016 20:01, John Levine wrote:
I suppose, but doing it as _._client._ 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



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Shumon Huque]

On Wed, Jan 13, 2016 at 5:24 AM, Tony Finch  wrote:

> John Levine  wrote:
> >
> > 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.)
>

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.)


> 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.
>

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?

_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.
>

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.

I like the idea of taking the server's service labels and prefixing
> 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John R Levine]

Yet the IANA registry seems to have a provision for registering
client service names (i.e. application specific identifiers used by
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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ray Bellis]

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
>  _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?

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._._, though.

Thinking more though, I actually prefer _._._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


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[George Michaelson]

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  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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Prefixed name spaces and DANE client TLSA

[John Levine]

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