On Mar 23, 2015, at 6:23 PM, Jan Včelák jan.vce...@nic.cz wrote:
This proposal continues to have fundamental problems that are not documented
in the draft.
- The statement about NSEC3 offline dictionary attacks are still possible
and have been demonstrated doesn't take into account trivial
On 24.3.2015 21:25, Paul Wouters wrote:
On Tue, 24 Mar 2015, Jan Včelák wrote:
The contents of zones quickly becomes visible, what with passive DNS,
DITL, people who connect in place X, and then reopen their laptop in
place Y, etc.
I know and I completely agree.
On the other hand, there
Paul, would you consider adding something like these, with whatever
modifications seem necessary? Maybe under Resource Records, since
that is where OPT is.
One thing that has been experience by many of us in different
organizations, and which actually has shown its head within
discussions with
i'm replying to several messages here, all from francis dupont.
Francis Dupont mailto:francis.dup...@fdupont.fr
Tuesday, March 24, 2015 1:39 PM
...
A 2mn timeout simply has no chance to scale.
i agree. it cannot scale. in addition, it's exceedingly easy to attack
responders which implement
In your previous mail you wrote:
I believe 5966bis already addresses your first point quite clearly.
(note: first point is to make TCP support mandatory)
For example, it says:
This document therefore updates the core DNS protocol specifications
such that support for TCP is
On Tue, Mar 24, 2015 at 06:02:34PM -0400, Dave Lawrence wrote:
ECS / EDNS client-subnet -- An EDNS option principally for carrying
information from a resolver to an authoritative server about
the general network location of a client of the resolver. This is
generally used by full service
ajs I have read draft-ietf-dnsop-negative-trust-anchors-02. I have
ajs some comments.
Thanks. These seem like reasonably comments and I'll fold them into the
doc.
Hope to have a new version out next week.
___
DNSOP mailing list
DNSOP@ietf.org
In your previous mail you wrote:
So I propose:
- make clear that TCP support is mandatory.
- allow servers to use the timeout they like, even a zero timeout
(the last point should be discussed). Note a zero timeout doesn't
mean send the response and close but send the response,
On Mar 24, 2015, at 4:42 PM, Francis Dupont francis.dup...@fdupont.fr wrote:
For example, it says:
This document therefore updates the core DNS protocol specifications
such that support for TCP is henceforth a REQUIRED part of a full DNS
protocol implementation.
= but has
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/23/15 10:31, Andrew Sullivan wrote:
if somehow the onion name leaked and ended up in the DNS, it's not a
big deal
*** Well, although you're right as far as *applications* are concerned,
this is still a big deal because humans are using
In your previous mail you wrote:
This document therefore updates the core DNS protocol specifications
such that support for TCP is henceforth a REQUIRED part of a full DNS
protocol implementation.
Sorry, I should have realized that RFC 5966 (August 2010) already
says
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/24/15 20:03, Alec Muffett wrote:
Hi Hellekin!
I would agree that leak avoidance is “a major” rather than “the prime”
point of having .onion reserved as a TLD.
*** Agreed. I came from the privacy side of the arguments, which tends
to
On Mar 24, 2015, at 3:39 PM, Francis Dupont francis.dup...@fdupont.fr wrote:
So I propose:
- make clear that TCP support is mandatory.
- allow servers to use the timeout they like, even a zero timeout
(the last point should be discussed). Note a zero timeout doesn't
mean send the
Hi Hellekin!
I would agree that leak avoidance is “a major” rather than “the prime”
point of having .onion reserved as a TLD.
There are many good reasons for reserving “.onion” as a TLD, including but
not limited to:
- avoiding leaks (above)
- not wasting resource on trying to resolve the
Alec, would you care to explain
the differences on the IANA
considerations between this
draft and the P2PNames draft
Woo! I'm honoured, but I am a considerably less IANA-informed schmuck than you
take me for. :-)
I've been heads-down in Tor and the wider Tor community for some time now, and
* Paul Hoffman [2015-03-24 13:57]:
On Mar 23, 2015, at 6:23 PM, Jan Včelák jan.vce...@nic.cz wrote:
- The statement about NSEC3 offline dictionary attacks are still possible
and have been demonstrated doesn't take into account trivial changes that
an operator can choose to take if they are
On 24.3.2015 13:57, Paul Hoffman wrote:
On Mar 23, 2015, at 6:23 PM, Jan Včelák jan.vce...@nic.cz wrote:
This proposal continues to have fundamental problems that are not
documented in the draft.
- The statement about NSEC3 offline dictionary attacks are still possible
and have been
On Thursday, January 15, 2015, Matthijs Mekking matth...@pletterpet.nl
wrote:
Hi wg,
IXFR with DNSSEC is suddenly not so small anymore. Do you recognize
this? Olafur and I have some ideas on keeping those zone transfers
small. Your feedback is appreciated.
Sorry for most of the following comments on
draft-ietf-dnsop-root-loopback-01 applicable to its appendices.
It is better to describe that the update of the zone can be delayed a
little bit as no NOTIFY message is sent to the root-on-loopback.
In Appendix A, the root servers listed allow AXFR
On Mar 24, 2015, at 11:11 AM, Warren Kumari war...@kumari.net wrote:
There is a paper Stretching NSEC3 to the Limit: Efficient Zone
Enumeration Attacks on NSEC3 Variants by Sharon Goldberg et al, which
covers some of the trivial solutions and explains why it won't work:
On 24.3.2015 19:11, Warren Kumari wrote:
On Tue, Mar 24, 2015 at 9:56 AM, Jan Včelák jan.vce...@nic.cz wrote:
On 24.3.2015 13:57, Paul Hoffman wrote:
On Mar 23, 2015, at 6:23 PM, Jan Včelák jan.vce...@nic.cz wrote:
This proposal continues to have fundamental problems that are not
documented
On Mon, Mar 23, 2015 at 6:38 PM, Jan Včelák jan.vce...@nic.cz wrote:
On 23.3.2015 18:26, Bob Harold wrote:
I think we might need to allow for more than one NSEC5 key and chain,
during a transition. Otherwise it might be impossible to later create a
reasonable transition process. This
On 24.3.2015 20:08, Bob Harold wrote:
On Mon, Mar 23, 2015 at 6:38 PM, Jan Včelák wrote:
On 23.3.2015 18:26, Bob Harold wrote:
I think we might need to allow for more than one NSEC5 key and chain,
during a transition. Otherwise it might be impossible to later create a
On 24.3.2015 19:20, Paul Hoffman wrote:
Again: a proposal for an operational change to DNSSEC needs to be explicit
about the tradeoffs, particularly when one of the options is you will be
considered unsigned by some resolvers when you implement this. The current
draft is not have this.
As we have more and more DNS over TCP (large responses, response
rate limitation, even TLS for privacy) I think we should fix the
way DNS over TCP is supposed to be handled by servers.
Quoting RFC 1035 4.2.2 TCP usage:
- The server should assume that the client will initiate
connection
On Tue, 24 Mar 2015, Francis Dupont wrote:
So I propose:
- make clear that TCP support is mandatory.
- allow servers to use the timeout they like, even a zero timeout
(the last point should be discussed). Note a zero timeout doesn't
mean send the response and close but send the response,
Some comments on draft-hoffman-dns-terminology
NODATA -- This is not an actual response code, but instead is the
combination of an RCODE of 0 (NOERROR) and an Answer section that is
empty. That is, it indicates that the response is no answer, but
that there was not supposed to be
On Tue, Mar 24, 2015 at 3:27 PM, Jan Včelák jan.vce...@nic.cz wrote:
On 24.3.2015 20:08, Bob Harold wrote:
On Mon, Mar 23, 2015 at 6:38 PM, Jan Včelák wrote:
On 23.3.2015 18:26, Bob Harold wrote:
I think we might need to allow for more than one NSEC5 key and
chain,
On Mar 24, 2015, at 10:41 AM, Matthäus Wander matthaeus.wan...@uni-due.de
wrote:
* Paul Hoffman [2015-03-24 13:57]:
On Mar 23, 2015, at 6:23 PM, Jan Včelák jan.vce...@nic.cz wrote:
- The statement about NSEC3 offline dictionary attacks are still possible
and have been demonstrated
Status of current WG Documents
In an effort to expedite the agenda along during the DNSOP meeting, we
wanted to give an update of Working Group Documents and where they stand.
draft-ietf-dnsop-child-syncronization
Now RFC 7477, complete with Errata!
draft-ietf-dnsop-as112-dname - In
On Tue, Mar 24, 2015 at 9:56 AM, Jan Včelák jan.vce...@nic.cz wrote:
On 24.3.2015 13:57, Paul Hoffman wrote:
On Mar 23, 2015, at 6:23 PM, Jan Včelák jan.vce...@nic.cz wrote:
This proposal continues to have fundamental problems that are not
documented in the draft.
- The statement about
31 matches
Mail list logo
