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 reall
Bernard Aboba wrote:
...
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,
Not so. Under exception (a) of clause 4.3 of RFC 2860, the IETF can require
IANA
Hi Robert,
Our process, as currently instantiated, has three stages after a
document is submitted to the IESG for review/approval:
1. AD Review -- the responsible AD reviews the document and
determines if is ready for IETF LC. Sometimes other things happen at
this stage, like review by cer
Date:Sun, 18 Sep 2005 10:09:07 -0400
From:Margaret Wasserman <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
I am not going to comment on the substance of the issues, or the
doc in question, as I haven't been following what is happening with
it, nor have a read a r
> Bernard Aboba <[EMAIL PROTECTED]> writes:
> > 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 respon
> 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, independe
In message <[EMAIL PROTECTED]>, Russ Allbery writes:
>Bernard Aboba <[EMAIL PROTECTED]> writes:
>
>> 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 suc
> 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
re
Hi Bernard,
At 9:31 PM -0700 9/19/05, Bernard Aboba wrote:
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. T
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:
Please remember, though, that most of my note was not meant to
express my own
technical opinion, it was an attempt to summarize
Bernard Aboba <[EMAIL PROTECTED]> writes:
>> 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 me
> 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
Bernard Aboba <[EMAIL PROTECTED]> writes:
> 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 dem
> 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
Hi Bernard,
[BA] Right. Margaret's message was technically wrong on a large number
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
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, mischaract
At 3:55 PM -0700 9/18/05, Stuart Cheshire wrote:
mDNS takes the approach
that local lookups should be distinguishable from global lookups and
accomplishes this through the use of a special local domain (.local).
This claim is one of the bits of misinformation that seems to be spread
about mDNS
Margaret Wasserman wrote:
[..]
We have a number of choices about how to proceed in this situation, but
before we talk about next steps, I would like to hear any feedback that
people might have regarding my summary of the discussion so far and the
conclusions that I have reached from it.
>(3) Separate, but perhaps underlying both of the previous issues,
>there seems be a fundamental disagreement about what technical
>approach we should take to link-local name lookup. LLMNR takes the
>approach that local lookups should use the same names as global
>lookups and that upper layers
Hi All,
As I am sure many of you have noticed, there was extensive discussion
during the IETF Last Call for "Link Local Multicast Name Resolution
(LLMNR)" specification that is currently available as
draft-ietf-dnsext-mdns-43.txt. Thanks to all who participated! The
discussion appears to h
20 matches
Mail list logo
