Christian Huitema wrote:
> NAT routers come to mind. DNSSEC
> is immune to such attacks, a big advantage in practice.
I'm afraid DNSSEC and some NAT interact terribly.
> Also, it is actually possible to improve on DNSSEC by introducing
> additional knowledge. If two domains have an establish re
On Tue, Jun 02, 2009 at 10:38:28PM +0900, Masataka Ohta wrote:
> Christian Huitema wrote:
>
> >>That is, security of DNSSEC involves third parties and is not end
> >>to end.
>
> > That is indeed correct. An attacker can build a fake hierarchy of
> > "secure DNS" assertions and try to get it accep
On Tue, 26 May 2009, The IESG wrote:
- 'IANA Registration of Enumservices: Guide, Template and IANA
Considerations '
as a Proposed Standard
This is an ops-dir review. I'm only superficially familiar with ENUM,
so take the comments with a grain of salt. I did not see major issues
with t
I was assigned this document as a secdir review.
I'm not sure I have any comments in that capacity.
However, I do have significant comments on the last call of this document.
I appreciate the work that has gone into this document. People have
worked hard to find examples, cases and even pithy
sa
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-geopri
... it's that, or my reading of RFC 2181 has gone horribly wrong.
The problem is this: the authoritative servers for a domain can easily
never be consulted for DNS data if the resource being looked up
happens to be available at the parent zone. That is,
bigbox.example.net's address and the
In message , Sab
ahattin Gucukoglu writes:
> ... it's that, or my reading of RFC 2181 has gone horribly wrong.
>
> The problem is this: the authoritative servers for a domain can easily
> never be consulted for DNS data if the resource being looked up
> happens to be available at the parent z
Bill Manning wrote:
> i think the distinction here might be characterised by
> the use of terms:
>
> -channel security
Don't try to confuse the terminology.
With the terminology of "channel", the paper addresses the issue
that security by channels between zones or zone admini
On 4 Jun 2009, at 04:06, Mark Andrews wrote:
In message >, Sabahattin Gucukoglu writes:
The problem is this: the authoritative servers for a domain can
easily
never be consulted for DNS data if the resource being looked up
happens to be available at the parent zone. That is,
bigbox.example.net
Sam,
Thanks for posting your review. It caused me to have a look at the
document, because I've been considering writing something of a missive
on my own. I have to say that I enjoyed reading this draft up to about
Section 3, and then I came to some problems. I'll spell those out in a
separ
At 12:22 03-06-2009, Sam Hartman wrote:
I appreciate the work that has gone into this document. People have
worked hard to find examples, cases and even pithy
sayings/architectural principles from many areas of the IETF. The
document tries to be broad and to look at a lot of options. I think
t
Hello,
Section 7.1 of draft-ietf-enum-3761bis-04 is about DNS Security. One
sentence caught my attention:
"Because of these threats, a deployed ENUM service SHOULD include
mechanisms to ameliorate these threats."
My reading of that is that a deployed ENUM service should include
mechani
12 matches
Mail list logo
