Re: Summary of the LLMNR Last Call

Bill Manning <> Fri, 30 September 2005 01:57 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1ELA9Q-0005yO-Lb; Thu, 29 Sep 2005 21:57:28 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1ELA9O-0005yB-CS for; Thu, 29 Sep 2005 21:57:26 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id VAA28717 for <>; Thu, 29 Sep 2005 21:57:23 -0400 (EDT)
Received: from ([] by with esmtp (Exim 4.43) id 1ELAH8-0006l3-Am for; Thu, 29 Sep 2005 22:05:28 -0400
Received: from [] (helo=[]) by with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42 (FreeBSD)) id 1ELA96-000Fkj-Cd; Fri, 30 Sep 2005 01:57:08 +0000
In-Reply-To: <>
References: <> <>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <>
Content-Transfer-Encoding: 7bit
From: Bill Manning <>
Date: Mon, 26 Sep 2005 12:26:13 -0700
To: Bernard Aboba <>
X-Mailer: Apple Mail (2.623)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: 7bit
Cc: Margaret Wasserman <>,, "Steven M. Bellovin" <>
Subject: Re: Summary of the LLMNR Last Call
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On Sep 20, 2005, at 10:55, Bernard Aboba wrote:

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

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.


> _______________________________________________
> Ietf mailing list

Ietf mailing list