Re: [DNSOP] [homenet] WGLC on "redact" and "homenet-dot"

In message , Ted Lemon writes: > > On Dec 21, 2016, at 3:31 PM, Stephane Bortzmeyer > wrote: > > What did we publish on classes? If you refer to > > draft-sullivan-dns-class-useless, it was never published (which is > > bad). > >

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

>I hereby, with full knowledge and prior consent, *refuse* that my ISP >(or the hotel where I stay) modify DNS responses. I gather you live in France, where the government can and occasionally does require ISPs to change DNS responses so that requests for domains that a court considers illegal in

Re: [DNSOP] [homenet] WGLC on "redact" and "homenet-dot"

On Dec 21, 2016, at 3:31 PM, Stephane Bortzmeyer wrote: > What did we publish on classes? If you refer to > draft-sullivan-dns-class-useless, it was never published (which is > bad). That’s what I was referring to. It was so obviously the right thing that it never occurred

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

> > adding complexity in the middle of any system increases the size of an > > attack surface. > > +1 This was described in detail several times (see for instance this > report > ) > and

[DNSOP] Also, the irony of a message about censoring being censored

> From: Paul Wouters > So my message to the dnsop list which also was sent to Vernon Schryver > just got bounced back to me. The Irony. > > Luckilly, there was a URL in there instead of just an RPZ policy number > encoded in a serial number, so I could look up the reason for

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

On Mon, Dec 19, 2016 at 10:38:46AM +0100, bert hubert wrote a message of 25 lines which said: > By this token any firewall is censorship and lies. Yet we still use > them. No, blocking a communication is harsh but is not a lie. Returning HTTP code 451 (RFC 7725) is

Re: [DNSOP] Role of informational RFCs Re: DNSOP Call for Adoption draft-vixie-dns-rpz

On Wed, Dec 21, 2016 at 10:04:38AM -0500, Suzanne Woolf wrote a message of 54 lines which said: > If the question is “Does the existence of an Informational RFC mean > people will think the IETF is endorsing or promoting a technology or > practice, and are they more

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

On Mon, Dec 19, 2016 at 08:58:23PM -0800, william manning wrote a message of 214 lines which said: > adding complexity in the middle of any system increases the size of an > attack surface. +1 This was described in detail several times (see for instance this report

Re: [DNSOP] [homenet] WGLC on "redact" and "homenet-dot"

Stephane Bortzmeyer writes: > What did we publish on classes? If you refer to > draft-sullivan-dns-class-useless, it was never published (which is > bad). As part of the IDNA discussion there is an RFC (or parts of it) pointing out how uesless classes are. I seem to remember it was from the

Re: [DNSOP] Second Working Group Last Call - draft-ietf-dnsop-nsec-aggressiveuse

On Wed, Dec 21, 2016 at 11:34:52AM -0800, 神明達哉 wrote a message of 143 lines which said: > - Title: "Aggressive use of NSEC/NSEC3" > > I think this should now be e.g., "Aggressive use of DNSSEC-validated > cache" because of the equal weight given to the aggressive use

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

On Mon, Dec 19, 2016 at 09:09:42AM +, Evan Hunt wrote a message of 20 lines which said: > I hereby, with full knowledge and prior consent, give my resolver > (which I own) *permission* to falsely tell my browser (which I also > own) that malware domains don't exist. I

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

On Wed, Dec 21, 2016 at 08:01:04PM +, Viktor Dukhovni wrote a message of 22 lines which said: > I am curious to understand how RPZ zone transfers are (intended to > be) secured. It is covered in section 12.3 of the draft (and in several other places). Basically,

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

On Tue, Dec 20, 2016 at 10:16:58AM -0500, tjw ietf wrote a message of 79 lines which said: > The draft is being present as "Informational", and the point here is to > document current working behavior in the DNS (for the past several years). ... > This starts a Call for

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

Hello, I will keep my feedback short and to the point. We have implemented RPZ across our resolvers and it has been a fantastic tool to stop botnet C and outbound DDoS attacks. I just wanted to say it has been an extremely valuable tool to us here at Rackspace and provide some positive

Re: [DNSOP] [homenet] WGLC on "redact" and "homenet-dot"

On Thu, Dec 15, 2016 at 05:50:11PM -0500, Ted Lemon wrote a message of 93 lines which said: > It would also make it not work for any client, and it would be in > direct contradiction to advice this working group published less > than a year ago. What did we publish on

Re: [DNSOP] Second Working Group Last Call - draft-ietf-dnsop-nsec-aggressiveuse

On Tue, Dec 20, 2016 at 07:38:08PM +, Warren Kumari wrote a message of 72 lines which said: > > * synthesis of NXDOMAIN from NSEC (obviously; that's the minimum) > > * synthesis of NXDOMAIN from NSEC3 (if no opt-out) > > * synthesis of NODATA from NSEC/NSEC3 > > *

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

Viktor Dukhovni wrote: > On Wed, Dec 21, 2016 at 12:39:55PM -0500, Matthew Pounsett wrote: > > > RPZ is not the ideal, but it works, and goes beyond being deployable–it is > > deployed. > > I am curious to understand how RPZ zone transfers are (intended to > be) secured. It sounds like the

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

In message <20161221200104.gk13...@mournblade.imrryr.org>, Viktor Dukhovni writes: > On Wed, Dec 21, 2016 at 12:39:55PM -0500, Matthew Pounsett wrote: > > > RPZ is not the ideal, but it works, and goes beyond being deployableit > is > > deployed. > > I am curious to understand how RPZ zone

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

On Wed, Dec 21, 2016 at 12:39:55PM -0500, Matthew Pounsett wrote: > RPZ is not the ideal, but it works, and goes beyond being deployable–it is > deployed. I am curious to understand how RPZ zone transfers are (intended to be) secured. It sounds like the reason for standardizing RPZ is to allow

Re: [DNSOP] Second Working Group Last Call - draft-ietf-dnsop-nsec-aggressiveuse

At Tue, 13 Dec 2016 14:13:27 -0500, tjw ietf wrote: > We felt another formal Working Group Last call was needed, though hopefully > shorter. > > This starts a Working Group Last Call for: > "Aggressive use of NSEC/NSEC3" > draft-ietf-dnsop-nsec-aggressiveuse > >

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

I wrote: > https://tools.ietf.org/html/draft-vixie-dns-rpz-04 > If a policy rule matches and results in a modified answer, then that > modified answer will include in its additional section the SOA RR of > It's not signed, but perhaps it could be with look-asside trust anchors, > although

[DNSOP] Also, the irony of a message about censoring being censored

So my message to the dnsop list which also was sent to Vernon Schryver just got bounced back to me. The Irony. Luckilly, there was a URL in there instead of just an RPZ policy number encoded in a serial number, so I could look up the reason for this block: The DCC Reputation database

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

On Wed, 21 Dec 2016, Vernon Schryver wrote: As I wrote on Monday, the final paragraph of section 6 on page 18 of https://tools.ietf.org/html/draft-vixie-dns-rpz-04 says: If a policy rule matches and results in a modified answer, then that modified answer will include in its additional

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

> From: Ted Lemon > It would be _nice_ if the browser, for example, could get some > kind of positive, signed assertion that some authority has claimed > that the domain in question is malicious (or whatever). As I wrote on Monday, the final paragraph of section 6 on page 18

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

On 21 December 2016 at 12:47, Ted Lemon wrote: > On Dec 21, 2016, at 12:39 PM, Matthew Pounsett wrote: > > None of those things are required by RPZ, but I believe they are required > by the hypothetical better alternative that a few people have suggested we

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

On Dec 21, 2016, at 12:39 PM, Matthew Pounsett wrote: > None of those things are required by RPZ, but I believe they are required by > the hypothetical better alternative that a few people have suggested we > should work on instead. To be clear, there is no real

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

On 21 December 2016 at 12:29, Ted Lemon wrote: > Practically speaking, none of these changes are _required_. The worse > case scenario is that if someone looks up a malicious domain, you get back > a bogus answer that doesn’t validate. The resolver reports "no answer" >

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

Practically speaking, none of these changes are _required_. The worse case scenario is that if someone looks up a malicious domain, you get back a bogus answer that doesn’t validate. The resolver reports "no answer" because an answer that doesn’t validate is no answer. The user sees that

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

On 21 December 2016 at 10:53, Paul Wouters wrote: > > And 1) should not need to break DNSSEC. IETF should come up with a > better solution for signaling a DNS lookup might be unhealthy for > the enduser. > > Other than returning an altered answer (pointing to an informational

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

> > No, this draft simply specifies what operators are already doing. Not > > because they are intent on destroying trust in the DNS or the Internet, > > but because they are forced to do this by governments, they need to > > protect their own network, they would like to protect their customers, >

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

In article you write: >>> Those malevolent actors are just as capable of using DNSSEC. >> >> A lot of the arguments I'm seeing here boil down to "my users are >> better off with a signed A record pointing to a site that installs >> Cryptolocker

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

Speaking as a large enterprise operator (over 100,000 employees and contractors at over 600 sites as well as a significant public Internet presence) that has DNSSEC signed all public zones, the majority of internal zones, and has DNSSEC validation enabled at all levels throughout our recursive DNS

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

On Wed, 21 Dec 2016, John Levine wrote: Those malevolent actors are just as capable of using DNSSEC. A lot of the arguments I'm seeing here boil down to "my users are better off with a signed A record pointing to a site that installs Cryptolocker than with an unsigned NXDOMAIN or SERVFAIL."

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

>Those malevolent actors are just as capable of using DNSSEC. A lot of the arguments I'm seeing here boil down to "my users are better off with a signed A record pointing to a site that installs Cryptolocker than with an unsigned NXDOMAIN or SERVFAIL." There may be a world in which that is true

Re: [DNSOP] Role of informational RFCs Re: DNSOP Call for Adoption draft-vixie-dns-rpz

On 21 Dec 2016, at 7:04, Suzanne Woolf wrote: Just for clarity— no one is proposing standards track for this document; the intended status has been consistently discussed as “Informational”. That "consistently" doesn't seem to apply to many people who have said +1 to the adoption of this

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

On 21/12/2016 14:54, Ted Lemon wrote: > I think the exit strategy for RPZ is DNSSEC. I don't follow this argument. RPZ is primarily used to protect end-users from visiting sites associated with malware, either because the A / result of a lookup resolves to a particular address, or

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

Since operator participation was mentioned, > this draft actively destroys trust in the DNS, which reduces trust in the > Internet overall. No, this draft simply specifies what operators are already doing. Not because they are intent on destroying trust in the DNS or the Internet, but because

[DNSOP] Role of informational RFCs Re: DNSOP Call for Adoption draft-vixie-dns-rpz

Hi, Just for clarity— no one is proposing standards track for this document; the intended status has been consistently discussed as “Informational”. In discussing RPZ, as we’ve seen with other technology in the past, there’s a difference between “the consequences of having a controversial

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

William, I think the exit strategy for RPZ is DNSSEC. We really need to figure out how to get people to be able to reliably and safely set up DNSSEC. Despite Olaf’s excellent documents, we don’t really have that yet. I don’t think that operating DNSSEC should be as scary as it is, but

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

On Dec 21, 2016, at 9:36 AM, william manning wrote: > this draft actively destroys trust in the DNS, which reduces trust in the > Internet overall. > is that really what you want out of the IETF? Why would we trust unsigned data from the DNS? If we did, why would

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

the complaints about operator participation in the IETF go back decades. no news there. in fact, there are operator driven fora for just such activities, DNS-OARC comes to mind. this draft actively destroys trust in the DNS, which reduces trust in the Internet overall. is that really what you

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

Vernon won't see this, since he has blocked my email, but here goes. I think it is a huge mistake to adopt this work within the IETF. Although the IEtF has, in the past, documented worst common practice, i suspect that this case is one where the WG chairs should tell the authors to take the work