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

>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

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

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

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

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.

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

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

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

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

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

[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

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

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

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

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

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,

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

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

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

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,

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

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

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

>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

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

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

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

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

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

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

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

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

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

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

[DNSOP] Prefixed name spaces and DANE client TLSA

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