Subject: [dnssd] WG last call on draft-ietf-dnssd-mdns-dns-interop-01

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Tue, 7 Jul 2015 03:46:39 +0000

Hi,

This email begins a two week WGLC on draft-ietf-dnssd-mdns-dns-interop-01, "On Interoperation of Labels Between mDNS and DNS".

Tim and I believe the author has addressed the issues first brought forward at IETF-92 and subsequently discussed on the WG mailing list. 

You can see the draft here:
http://www.ietf.org/id/draft-ietf-dnssd-mdns-dns-interop-01.txt

Please send your comments or feedback to the list.

The WGLC ends on July 20th (Monday).

We will discuss/consider the result of the WGLC at the dnssd session at IETF-93 in Prague, which is scheduled for 9AM Wednesday, July 22.

- Ralph

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Wed, 15 Jul 2015 14:28:52 +0000

Reminder - the WG last call for draft-ietf-dnssd-mdns-dns-interop is in progress and we will discuss any last call comments during the WG meeting in Prague.

- Ralph

> On Jul 6, 2015, at 11:46 PM 7/6/15, Ralph Droms (rdroms) <[email-masked]> wrote:
> 
> Hi,
>

---

From: Dave Thaler <[email-masked]>
Date: Sat, 18 Jul 2015 19:22:39 +0000

I read draft -01 and it looks good to me, modulo a few editorial nits:

1) First sentence of section 3 missing end parenthesis:
>   Any interoperability between DNS (including prevailing operational
>   conventions and other resolution technologies will require

I believe the end parenthesis belongs after "conventions".

2) Security Considerations:
>   This memo presents some requirements for future development, but does
>   not specify anything.  Therefore, it has no implications for security.

The second sentence does not logically follow from the first sentence.
Specifically, does this memo surface any special requirements for security? 
If not, just say there are no additional security-specific requirements.

3) Appendix A: Add note to RFC editor to remove this section before publication?

Dave

-----Original Message-----
From: dnssd [mailto:[email-masked]] On Behalf Of Ralph Droms (rdroms)
Sent: Wednesday, July 15, 2015 7:29 AM
To: [email-masked]
Subject: Re: [dnssd] WG last call on draft-ietf-dnssd-mdns-dns-interop-01

- Ralph

> We will discuss/consider the result of the WGLC at the dnssd session at IETF-93 in Prague, which is scheduled for 9AM Wednesday, July 22.

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

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 18 Jul 2015 22:29:37 +0200

> I believe the end parenthesis belongs after "conventions".

Thanks, yes.

> If not, just say there are no additional security-specific requirements.

Well, _I_ don't think there are any more.  Doug seems to think so, but
I can't exactly make out what he wants.

> 3) Appendix A: Add note to RFC editor to remove this section before publication?

Sure, thanks.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Sun, 19 Jul 2015 06:31:35 +0200

>> 3) Appendix A: Add note to RFC editor to remove this section before publication?

Dear Andrew,

As noted in
https://www.kb.cert.org/vuls/id/550620
https://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-03#section-3.9.4.1
https://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-03#section-3.9.5

There are specific and significant security concerns related
to locally defined resources conveyed by mDNS. Interop
details relating to profiles might benefit security by
including a strategy to ascertain whether zones or labels
may have been established using mDNS via a proxy into DNS.

This might include the detection of a non-compliant IDNA
label or resources containing RFC1918 address space or
addresses below a ULA prefix.

Regards,
Douglas Otis

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 19 Jul 2015 09:21:13 +0200

Hi,

On Sun, Jul 19, 2015 at 06:31:35AM +0200, Douglas Otis wrote:
> to locally defined resources conveyed by mDNS.

I'm sorry, but I simply do not agree with your interpretation of those
reports and _anyway_ I don't see how those are in related to the
question of how you make a lowest common denominator naming convention
across multiple resolution mechanisms.  You have repeated the claim
that these are relevant, but you have provided not one shred of
evidence for that claim, and you seem to be conflating mDNS and DNS-SD
in the way you talk about this matter.

> Interop

Given the way the proxy document works, I don't believe that the risks
are the ones you seem to think.  Moreover, I think that would be a
security issue for the proxy document, not this one.
 
> addresses below a ULA prefix.

This document has absolutely nothing to say about the RDATA fields
returned in any resolution request, and I don't think that has
anything to do with what it is trying to address.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Sun, 19 Jul 2015 13:46:21 +0200

On 7/19/15 9:21 AM, Andrew Sullivan wrote:
> across multiple resolution mechanisms.

Dear Andrew,

I see mDNS and DNS-SD when populated from a hybrid scheme as
representing the same fruit.  Both mDNS and DNS-SD are able
to respond with sizable RRsets by design.  Responses that
may only be suitable with local exchanges structured to
facilitate service browsing.

Also, in the case of the hybrid scheme, a TLD of say '.home'
is using Ambiguous Local Qualified Domain Name (ALQDN) space
(see RFC7368). TLDs containing such resources are not held
to common conventions and may allow visual conflicts, for
example.  It seems provincial to suggest only .home or that
only IDNA compatible names are to be used in conjunction
with an mDNS/DNS-SD hybrid scheme.

As such, a common naming convention may not exist. When a
naming dichotomy is ignored, whether '.home', '.onion', or
perhaps '.domů', resulting incongruities may carry
substantial security risks.  A practical solution may demand
a strategy that excludes the majority of mDNS resources
structured as DNS-SD from being directly seen on the
Internet. Establishing guidance to handle very different
name spaces might be seen as a type of profile.

Less will be accomplished asserting mDNS/DNS-SD issues are
matters for DNS or the Hybrid document to handle since both
establish separate name spaces while also introducing many
incompatible naming convention issues and similar security
issues.

Regards,
Douglas Otis

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 20 Jul 2015 13:11:28 +0200

Hi,

On Sun, Jul 19, 2015 at 01:46:21PM +0200, Douglas Otis wrote:
> representing the same fruit.

You seem to have a category mistake here.  DNS and mDNS are both
resolution technologies -- two of the ones that can be used with
DNS-SD.  DNS-SD really just specifies various records, the relevant
record formats, and how to interpret the owner name of those records.
In DNS-SD, like in SRV, a pattern in the owner name is used as an
in-band signal to pack three distinct data into a single message
carrier (the owner name).  So don't actually understand what it means
to say "mDNS and DNS-SD when populated from a hybrid scheme".

> facilitate service browsing.

What are "Responses that may only be suitable with local exchanges"?
What is a "local exchange" anyway?

> example.

It seems to me that, if you're looking up ALQDNs, you're already out
of the DNS.  If the service isn't limiting that lookup, isn't there a
problem anyway?

> substantial security risks.

Yes.  That's an excellent reason to prefer a single global resolution
namespace, because unless you're following a single set of rules you
run the risk of opening a hole.  I think we've established that we
want to add some sort of sentence to the security considerations that
says that there's some danger in having multiple resolution contexts.  But is there something _else_ to say?

> A practical solution may demand

That all may well be, but I think it's not what this document is
about.  You seem to understand that, because it's what you're
complaining about, yet you want to change it.  But it's as though
you're complaining about the cargo-hauling capacity of a sports car: I
think if you want what I think you want, you need a different
document.  I'm not even sure it is a document that belongs in this WG;
maybe mif?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]