Subject: Re: Summary of the LLMNR Last Call

From: Bernard Aboba <[email-masked]>
Date: Mon, 19 Sep 2005 16:52:41 -0700 (PDT)

Stuart Cheshire said:

"This claim is one of the bits of misinformation that seems to be spread
about mDNS for some reason. It's repeated so often that people who
haven't read the draft assume it's true."

[BA] Right.  Margaret's message was technically wrong on a large number
of points, mischaracterizing mDNS, LLMNR and even DNS.  

Stuart continues:

"Even on Mac OS 9, five years ago, if you looked up "www.ietf.org" and had
no unicast DNS servers configured, it would look it up via mDNS instead.
The difference is that we were profoundly nervous about the implications
of doing this without adequate security, which is why
draft-cheshire-dnsext-multicastdns.txt allows multicast lookups for
non-local names, but says:"

[BA] Completely agree.  Sending unsecured queries for FQDNs via a 
link-scope multicast protocol is potentially dangerous.  This should only 
be done in situations where the security concerns can be addressed.  This is why 
the LLMNR specification describes usage restrictions (Section 2) as well as 
authentication mechanisms (Section 5.3).

   (14. Enabling and Disabling Multicast DNS)

   The option to fail-over to Multicast DNS for names not ending
   in ".local." SHOULD be a user-configured option, and SHOULD
   be disabled by default because of the possible security issues
   related to unintended local resolution of apparently global names.

[BA] The LLMNR specification contains similar language, except using a MAY 
instead of a SHOULD:

"  While these conditions are necessary for sending an LLMNR query, they
   are not sufficient.  While an LLMNR sender MAY send a query for any
   name, it also MAY impose additional conditions on sending LLMNR
   queries.  For example, a sender configured with a DNS server MAY send
   LLMNR queries only for unqualified names and for fully qualified
   domain names within configured zones."

The reason that this is only a MAY is because if security mechanisms 
are in place (DNSSEC, TSIG, IPsec) then queries for FQDNs may be sent 
securely.

[Stuart]

   (24. Security Considerations)

   When DNS queries for *global* DNS names are sent to the mDNS
   multicast address (during network outages which disrupt communication
   with the greater Internet) it is *especially* important to use
   DNSSEC, because the user may have the impression that he or she is
   communicating with some authentic host, when in fact he or she is
   really communicating with some local host that is merely masquerading
   as that name.

[BA] Agreed. Section 5.3 of the LLMNR specification describes the use 
of DNSSEC as well as other security mechanisms such as TSIG and IPsec.  
Use of LLMNR with TSIG has been demonstrated in running code.

[Stuart]

The difference between mDNS and LLMNR is not in their lookup of global
names, but that mDNS *also* designates a special sub-tree of the
namespace where users explicitly have different security expectations.

[BA] Actually, LLMNR and mDNS don't differ in this respect.  LLMNR also 
enables use of special sub-trees.  As an example, Windows implementations 
today treat single-label names specially; queries for these names are 
never sent to the DNS, only over NetBIOS.

However, LLMNR, while describing the use of special sub-trees, does not 
prescribe the special sub-tree that implementations should use.  Some
implementations might designate the single-label space as special;
others might use ".local".  

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

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 19 Sep 2005 20:41:46 -0400

Hi Bernard,

>of points, mischaracterizing mDNS, LLMNR and even DNS.

I would be very interested in understanding what technical errors I 
made and I would appreciate if you would share the details with me, 
perhaps off-line.  Please remember, though, that most of my note was 
not meant to express my own technical opinion, it was an attempt to 
summarize the issues that were raised by others in this discussion.

One way to address a technical concern is, of course, to convince the 
person (or people) who raised the concern that their issues are 
already appropriately addressed in the specification.

Margaret

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 19 Sep 2005 21:31:05 -0700 (PDT)

> I would be very interested in understanding what technical errors I made and I
> would appreciate if you would share the details with me, perhaps off-line.

The message sent to the IETF list contains several major technical errors, 
including:

a. Confusing DNS resolver behavior with the behavior of LLMNR 
implementations.  The sending of .local queries to the global DNS, while 
potentially a serious problem, results from the behavior of existing DNS 
resolver implementations.  This problem exists today on the vast 
majority of Internet hosts, which do not implement either mDNS or 
LLMNR.  Given this, putting language into the LLMNR specification 
to "fix" an orthogonal issue makes no sense. 

Even fixing the issue in another IETF specification could prove sticky, 
because it can be argued that the IANA has authority over the allocation of 
new TLDs such as ".local" not the IETF, which is why the DNSEXT WG 
recommended early on that the ".local.arpa" domain be used instead of 
".local". 

b. Confusion between security issues and namespace separation.  In 
peer-to-peer name resolution protocols, it is possible for a responder to 
demonstrate ownership of a name, via mechanisms such as DNSSEC.  It is 
also possible for a responder to demonstrate membership in a trusted 
group, such as via TSIG or IPsec.  If DNSSEC is available, spoofing 
attacks are not possible, and querying for FQDNs does not expose the 
sender to additional vulnerabilities.  Both the mDNS and LLMNR 
specifications agree on this point.

c. Lack of consideration of existing practice.  Internet hosts have used 
multiple name resolution mechanisms based on a single API for more than 
two decades, with no ill effects.  For example, *NIX systems have utilized 
/etc/host files, NIS and DNS;  Windows systems utilize LMHOSTS, DNS and 
NetBIOS.  The issue of integration of multiple name services is dealt 
within multiple RFCs, including RFC 1001 which defines NetBIOS and 
describes how it coexists with DNS and RFC 2937, which describes the Name 
Service Search Option for DHCP.  In practice, hundreds of millions of 
Internet hosts use these mechanisms every day.  If you type "http://foo/" 
in the browser of a Windows host, a DNS query for "foo" is not sent over 
the wire; only a NetBIOS query is sent.  This is not rocket science. 

> Please remember, though, that most of my note was not meant to express my own
> technical opinion, it was an attempt to summarize the issues that were raised
> by others in this discussion.

The job of an IESG member is not to repeat mistatements, it is to use their 
judgement.  In this and other instances, the IESG appears to have lost sight 
of its mission.  The best interest of the Internet community lies not in 
blocking the publication of documents that fall outside today's orthodoxy, 
but rather in providing information to the Internet community.  In this case, 
that interest would be best served by publishing *all* documents 
relating to mDNS and LLMNR, especially the ones that the DNSEXT WG has found 
most objectionable (such as DNS-SD, and Bill Manning's DISCOVER OPCODE draft). 

I must admit that at one point, I did not see value in funding the RFC 
Editor to publish documents outside of the IETF process, via the RFC 
Editor Individual Submission route, described in RFC 3932.  However, now 
it has become abundantly evident that this represents an important 
safety mechanism that needs to be preserved going forward.

---

From: Russ Allbery <[email-masked]>
Date: Mon, 19 Sep 2005 22:01:39 -0700

Bernard Aboba <[email-masked]> writes:

> peer-to-peer name resolution protocols, it is possible for a responder
> to demonstrate ownership of a name, via mechanisms such as DNSSEC.  It
> is also possible for a responder to demonstrate membership in a trusted

We agree that home burglary is a serious problem.  This is why we
recommend that everyone hire an armed guard for their house.  If your
house is monitored by armed guards, burglary is very unlikely.  Given that
there is an effective security mechanism available, there's really no need
to consider simple deterrants that won't provide true security.

> two decades, with no ill effects.

"No ill effects" is a horribly inaccurate description of the effects of
that design.  A much more accurate description would be that Internet
hosts have used multiple name resolution mechanisms through a single API
out of necessity for more than two decades, have suffered frequent ill
effects up to and including major outages because of it, but have
struggled along with that design because there are some features provided
by it that are too useful to completely dismiss in general.  That being
said, most systems attempt to avoid using those features when feasible and
attempt to make all sources of information match exactly to avoid the
serious and often hard-to-diagnose problems of conflicting information.

If you think that using /etc/hosts, NIS, and DNS at the same time on
systems to provide name resolution is a *success* story, your perceptions
of the practical problems of name resolution in Internet hosts is
drastically different than mine.  You've also had to maintain far less
code to try to work around bizarre inconsistencies in gethostbyname
responses than I have.

> safety mechanism that needs to be preserved going forward.

I suppose that's one reaction to a general IETF mailing list consensus
that a protocol raises serious concerns.  I don't think it's a
particularly useful one, though.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 19 Sep 2005 23:20:15 -0700 (PDT)

> to consider simple deterrants that won't provide true security.

Not sure what this has to do with a link-scope resolution protocol 
supporting  name partitioning and DNSSEC.  LLMNR provides a simple 
deterrant in the case where security is available -- restricting the names 
for which queries are sent.  This is *exactly* the same mechanism used by 
mDNS. 

> attempt to make all sources of information match exactly 

The NetBIOS and DNS names spaces have coexisted for more than two decades 
without requiring exact matches, because they do not overlap.  Similarly, 
"exact matches" can be ensured via security schemes such as DNSSEC while 
permitting overlapping name spaces.  So "exact matches" are neither 
sufficient nor necessary. 

*Both* the mDNS and LLMNR specifications agree on this point. The only difference 
is that mDNS uses ".local" for partioning, while it is suggested (but not required) 
that LLMNR implementations use single-label names.

---

From: Russ Allbery <[email-masked]>
Date: Mon, 19 Sep 2005 23:32:36 -0700

Bernard Aboba <[email-masked]> writes:

>> house is monitored by armed guards, burglary is very unlikely.  Given
>> that there is an effective security mechanism available, there's really
>> no need to consider simple deterrants that won't provide true security.

> deterrant in the case where security is available -- restricting the
> names for which queries are sent.  This is *exactly* the same mechanism
> used by mDNS.

It was a possibly too sarcastic way of pointing out that I don't think
DNSSEC is an answer to this concern.

The difference between LLMNR and mDNS is one that I think is important.
This is a place where a SHOULD is the least that needs to be said, and a
MAY is simply not strong enough, not only for security reasons, but partly
for that.  If you said MAY *if* DNSSEC or TSIG is used, SHOULD otherwise,
I would be somewhat less concerned, but still dubious.

> The NetBIOS and DNS names spaces have coexisted for more than two
> decades without requiring exact matches, because they do not overlap.

If LLMNR required that the namespaces not overlap, I believe that would
address many (although not all) of the concerns that were raised here.

> Similarly, "exact matches" can be ensured via security schemes such as
> DNSSEC while permitting overlapping name spaces.

Is .com signed yet?

> *Both* the mDNS and LLMNR specifications agree on this point. The only
> difference is that mDNS uses ".local" for partioning, while it is
> suggested (but not required) that LLMNR implementations use single-label
> names.

That's a very important difference to me.

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 20 Sep 2005 04:53:28 -0400

Hi Bernard,

I'll start with the process portion of your message and answer the 
technical portion in my next note...

At 9:31 PM -0700 9/19/05, Bernard Aboba wrote:
>judgement.

We apparently disagree about the job of an IESG member WRT IETF LC...

I believe that the purpose of an IETF LC is to determine if the IETF 
has consensus to publish a document.  I believe that my job, during 
IETF LC, is to judge whether that consensus exists -- which is 
usually demonstrated through lack of any objection.  In this case, 
there were significant objections to publishing this document, and I 
do not believe that IETF consensus currently exists to publish this 
document as a Proposed Standard RFC.

An IESG member's technical judgement is used at two phases:  AD 
Review and IESG Review.  This document was submitted for publication 
because the DNSEXT WG thought that it was ready for publication as a 
Proposed Standard RFC.  This document then passed AD Review and was 
sent to IETF LC because, in my judgement, it was ready for 
publication at PS.  The community disagreed.

>In this and other instances, the IESG appears to have lost sight

I absolutely disagree that the best interests of the community would 
be served by publishing all of these documents as Proposed Standard 
RFCs.  It might make sense to publish some or all of them (I haven't 
actually read all of them) as Informational RFCs, and that is one of 
the potential paths forward here.
Publication of a Proposed Standard RFC requires IETF LC and IETF 
community consensus.  Publication of an Informational RFC does not.

Another possible path for LLMNR is for the DNSEXT WG to understand 
the objections raised by the community, resolve those concerns (by 
changing the document, educating the community or other means) and 
present an updated document that will reach consensus in the 
community for publication as a Proposed Standard.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 20 Sep 2005 05:16:22 -0400

Hi Bernard,

>to "fix" an orthogonal issue makes no sense.

You might note that in the technical discussion, I argued _against_ 
the idea that this is a problem with LLMNR.  Personally, I consider 
the fact that mDNS attaches special semantics to .local to be a 
problem with mDNS.

However, reading over the very large number of messages in this 
thread, it is clear that my arguments were not persuasive enough to 
change the views of the people who raised this objection, and that 
the consensus view expressed during IETF LC was that we should not 
publish LLMNR until this issue is addressed.  I made my best attempt 
in my summary message to fairly represent the view of the community 
as I saw it expressed in this debate, but I may not have done a great 
job because it is not a view that I personally hold.

>specifications agree on this point.

I read and re-read the LLMNR Security Considerations section hoping 
to find a mandatory-to-implement security mechanism, so that I could 
use that fact to counter the points that were raised in IETF LC, and 
I couldn't find one.  If there is any mandatory-to-implement security 
in LLMNR, could you please point out what it is and where the 
document indicates that it is required?

Absent any mandatory-to-implement security, we sometimes accept an 
applicability statement that explains the environments in which it is 
safe to use a protocol without any protocol-specific security 
mechanism, but I didn't find that in the LLMNR document either.  Is 
it there?

Given that I could not find either of these things, it is my 
technical opinion that LLMNR creates new threats that are not 
adequately addressed in the document, and these threats need to be 
addressed before the document is sent to the IESG for review.  I 
realize that these threats already exist in deployed code, but 
existing practice is not the only criteria that we use for assessing 
whether a specification is suitable for publication as a Proposed 
Standard.

I missed this issue during my AD Review, for which I apologize. 
However, I am confident that if the community had not caught this 
issue, one of the other IESG members would have raised this issue 
during IESG review.

Margaret

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 20 Sep 2005 06:05:38 -0700 (PDT)

> You might note that in the technical discussion, I argued _against_ the idea
> that this is a problem with LLMNR.  Personally, I consider the fact that mDNS
> attaches special semantics to .local to be a problem with mDNS.

If the DNSEXT WG wants to document recommended resolver behavior with 
respect to the .local domain, it can do so.  However, your message essentially 
*orders* the WG to do so, as a precondition for publishing any documents on 
the topic.  That is inappropriate. 

> applicability statement that explains the environments in which it is safe to
> use a protocol without any protocol-specific security mechanism, but I didn't
> find that in the LLMNR document either.  Is it there?

Yes, it is. 

>From Section 5.2:

   Limiting the situations in which LLMNR queries are sent, as described
   in Section 2, is the best protection against these attacks.  

>From Section 2:

   While these conditions are necessary for sending an LLMNR query, they
   are not sufficient.  While an LLMNR sender MAY send a query for any
   name, it also MAY impose additional conditions on sending LLMNR
   queries.  For example, a sender configured with a DNS server MAY send
   LLMNR queries only for unqualified names and for fully qualified
   domain names within configured zones.

Is this issue only about whether the MAYs are to be upgraded to a SHOULD 
or MUST?

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 20 Sep 2005 12:19:34 -0400

>to consider simple deterrants that won't provide true security.
DNSsec is very important for other reasons, such as the current 
pharming attacks.  The risks have been known in the security community 
since at least 1991, and publicly since at least 1995.  The long-
predicted attacks are now happening.  We really need to get DNSsec
deployed, independent of mDNS or LLMNR.  Given that there is now some 
forward progress on DNSsec, it's not at all unreasonable for either or 
both of those specs to rely on it to solve some of their particular 
security risks.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 20 Sep 2005 10:55:56 -0700 (PDT)

> both of those specs to rely on it to solve some of their particular 

Couldn't agree more.  But if I'm not mistaken, the current DNSSEC 
specifications do not mandate that DNS stub resolvers be DNSSEC-aware 
validating, which is what would be required for use in a peer-to-peer name 
resolution protocol.  There is also the DNSEXT WG edict that mDNS/LLMNR 
not share a cache with DNS, which makes it difficult for mDNS/LLMNR to 
utilize trust anchors or acquired keys present in the DNS cache.

---

From: Ned Freed <[email-masked]>
Date: Tue, 20 Sep 2005 11:53:06 -0700 (PDT)

> to consider simple deterrants that won't provide true security.

We do have a strong tendency to let the best be the enemy pf the good, don't
we?

> code to try to work around bizarre inconsistencies in gethostbyname

I could not agree more. This particular hairball has been a consisent source of
support problems around two decades now. In fact it may have set some sort of
record: I cannot think of anything else we were using 20 years ago is still
causing exactly the same sorts of problems it caused back then.

				Ned

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Sep 2005 12:50:39 +0200

Bernard Aboba wrote:
...
> new TLDs such as ".local" not the IETF, 

Not so. Under exception (a) of clause 4.3 of RFC 2860, the IETF can require
IANA to reserve such a pseudo-TLD. If anybody thinks we should do so, feel free
to write a short draft.

The advantage of doing so would be that operational recommendations for
special handling of this pseudo-TLD by resolvers could then be made.

     Brian

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 23 Sep 2005 14:29:57 +0200

Brian E Carpenter wrote:
 
> Under exception (a) of clause 4.3 of RFC 2860, the IETF can
> require IANA to reserve such a pseudo-TLD. If anybody thinks
> we should do so, feel free to write a short draft.

How about adding it to 2606 ?  2606bis could add a note that
".local" might be used for local purposes specified elsewhere.

Maybe plus a reference to www.as112.net if they want to do
something with these pseudo-TLDs.  

It could also say that whois.iana.org should answer queries
for these pseudo-TLDs - e.g. "local not found - see BCP 32".

And add your IANA-MoU 2860 4.3 reference to 2606bis.  While
we're at it we could also add the RfC 3696 "toplabel" rule:
there is no TLD or pseudo-TLD without at least one ALPHA.

                          Bye, Frank

---

From: Bill Manning <[email-masked]>
Date: Mon, 26 Sep 2005 12:26:13 -0700

> utilize trust anchors or acquired keys present in the DNS cache.

not to  distract too much from the LC issues....  but there is an 
ongoing effort
to define ways to have a standard API for validation by applications.  
Part of
that work is understand what the term "cache" means in this context.   
And does
validation have to work in lockstep w/ resolution?   Regardless, a 
common API
is highly valuable.  there have been a couple of meetings on these 
issues already
and we would be glad to have more inputs.

--bill