Re: [DNSOP] I-D Action: draft-ietf-dnsop-maintain-ds-04.txt

[Matthijs Mekking]

I see that IESG has approved this document, but I am still wondering this:

On 01-12-16 13:20, Matthijs Mekking wrote:

Hi,

I read this again. I still wonder if in the case of DNSSEC Delete
Algorithm it wouldn't be easier to say: In case the DNSSEC algorithm is
0, the Digest/Public Key MUST be ignored.

This way, you don't have to change the CDS/CDNSKEY format defined in RFC
7344, most likely causing less problems with deployed software.


Best regards,
  Matthijs

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Viktor Dukhovni]

On Mon, Jan 09, 2017 at 03:51:31PM +, Vernon Schryver wrote:

> Note that the vast majority of clients of RPZ rewriting resolvers are
> stubs that don't do validation

So far, and at present, correct.  Validating resolvers (unbound
and the like) are seeing deployment on servers first, including
some of the caches queried by said stubs.  (Far from representative
of course, My home OpenWRT router runs a validating unbound.)

> but trust header bits saying that a
> resolver operated by a third party did the validation.

But not this.  The stubs in question are generally security oblivious,
and don't in any sense "trust" that any validation happens upstream.

> I think that's
> wrong, evil, nasty, unethical, a Major Human Rights Issue, and blah
> de blah de blah, but it's also something no one seems willing and able
> to change.

And this part is both irrelevant, and IMHO inappropriately dismissive
of legitimate concerns expressed upstream.  We won't all agree,
but we should be held to a higher standard on the manner of the
discourse.

--
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vernon Schryver]

> From: Philip Homburg 

> 1) If the traver's laptop/phone uses Heathrow Airport resolvers then Heathrow

>4) DNS is not really private so Google may offer their DNS services over HTTPS
> 5) Governments may force Google to block popular sites, so users switch to
>other DNS resolvers, again over HTTPS.

See https://developers.google.com/speed/public-dns/docs/dns-over-https
but I don't know how clients bootstrap that API without classic DNS.

Regardless of that, what if Heathrow Airport deploys HTTPS proxies to
block child porn, drug, terrorist, and malware web pages as well as
attempts by corrupted laptops and smart phones to bypass blocks on
port 53 and reach evil or merely unfiltered DNS/HTTPS servers including
those run by Google?


> In that sense I don't care that much about the more philosophical arguments
> arguments against rpz. If you care about DNS, run a local DNSSEC validating
> resolver that does roadblock avoidance and possibly falls back to 
> TLS or HTTPS to some trusted resolver.

Everyone should do that, if necessary without knowing they're doing
it, such as with the help of validating resolver code in broswers.
Something like that is required to stop the fraud that is commercial PKI.
(Google's two alternatives to DANE are great for the Alexa 500 and
maybe the Alexa 5000, but useless or worse for the Alexa 100,000,000.)

   ..

] From: =?UTF-8?B?56We5piO6YGU5ZOJ?= 

] But I think the document itself is very useful, so it would be nice if
] it's made more publicly available in other form, e.g., some
] white-paper kind or at a popular blog site.

That will happen whether or not the text gets an RFC number.  (If it
doesn't get a number, of course I will remove the IETF mumbo-jumbo.)
The current de facto standard status of RPZ suggests finding sufficient
popular web sites for publication is not an issue.

Disclaimer: Many people including the other author want the draft to
get an RFC number.  But my considered reaction the threats to not
publish, the demands to not publish without what I see as ill conceived
or worse fixes, and various other sentiments is more like
"Please don't throw me in the briar patch."
https://www.youtube.com/watch?v=S7tyhpWiZyM


] its not just ugly 

Yes, RPZ is a nasty, ugly, evil kludge that would not exist if I were
in charge of the Internet.

]   but also has some
]   inherent flaws, such as that not all domain names can be represented
]   due to length limitation.

Yes, but do you know of a real life example cannot be rewritten because
the RPZ trigger name would be too long?


]  In fact, not all existing implementations
]   of RPZ-like feature use this form as the primary way of rule
]   configuration (unbound is one example I happen to know of, and from
]   a quick look knot resolver also seems to adopt its own configuration
]   syntax).

Distributed blacklisting is one of or the most powerful aspect of RPZ.
I think (perhaps mistakenly) that the new blocking mechanism in
Unbound 1.6.0 lacks that aspect.

In addition, there is an RPZ patch for Unbound versions 1.5.4 through
1.6.0 that uses a separate daemon that acts like a slave master for
policy zones using AXFR/IXFR/NOTIFY.  However, I stopped maintaining
and deleted the patches for version 1.5.4 through 1.5.8 long ago.
Another caveat is that the work was for hire and so the daemon and its
interface .so are not open.  The patches to Unbound are open and have
been offered to NLnet Labs.


Vernon Schryverv...@rhyolite.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-01.txt

[Mark Andrews]

TSIG and SIG(0) (not yet covered by the draft) require reversable
modifications of the message.  I would be appending a new additional
record (code TBA) and removing it which contains the addresses.  I
would not be modifying an existing OPT record.  Nor would I be
adding a new OPT record.  Modifying/adding a opt record requires a
lot more, error prone, work to add and reverse the changes to make
TSIG and SIG(0) work.

The additional section count would be increased by 1.

TSIG / SIG(0) may now be followed by this record.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-ttl-stretching-00.txt

[Brian Hartvigsen]

> 
> > NOTE: I believe that there may be (non-Google) IP associated with
> > this. A lawyer will be filing the IPR disclosure later today (time
> > zone differences, etc).
> 
> The two approaches are somewhat different, and so at least one of them
> may not be covered by this patent.
> 
> Yup. The IPR disclose was about IPR belonging to Xerocole. Xerocole was 
> acquired by Akamai in March 2015. I believe that David will discuss the IPR 
> with his employer.

Thought I should point out that Cisco (previously OpenDNS) also has IPR in this 
area (tmk predates Xerocole.)  Not sure if there is anything to be done at this 
time, but just thought I should put that out there.

.:|:.:|:.
Brian Hartvigsen
Manager, Site Reliability Engineering
Cisco Umbrella


signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[神明達哉]

On Tue, Dec 20, 2016 at 7:16 AM, tjw ietf  wrote:

> 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).
> It is obvious that some feel this draft is a large mistake, but like
> edns-client-subnet, more operators are deploying this than one is aware of.
>
> This starts a Call for Adoption for draft-vixie-dns-rpz
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-vixie-dns-rpz/
>
> Please review this draft to see if you think it is suitable for adoption by
> DNSOP, and comments to the list, clearly stating your view.

I'm still reading the 04 version of draft-vixie-dns-rpz and intending
to make comments on it later, but I'd like to respond to the call
first: I do not think it's suitable for dnsop to adopt the draft in
its current form, with the intent of "just describing currently
deployed practice", and (as I guess) with the intent of eventually
publishing as an (Informational) RFC.

But I think the document itself is very useful, so it would be nice if
it's made more publicly available in other form, e.g., some
white-paper kind or at a popular blog site.  If the adoption means
polishing the document for that goal (although I don't think it's the
intent for this call), I'd support it.

Also, if we're really willing to work on a "standard, interoperable
DNS firewall specification" without worrying about substantially
changing the current practice/implementation, and if the adoption
means the first step for that goal (and so the final publication could
be totally different and may not be compatible with the existing
standard), then I'd support it.  But, again, I suspect that's not the
intent of this call.

Some more specific rationale for this opinion below:

- As I believe most people, and perhaps including the draft authors or
  RPZ implementations, agree, it's an ugly hack to use the standard
  DNS zone to represent the firewall rules.  It might have been a
  convenient way to implement the idea initially (e.g, we can use the
  zone transfer behavior to distribute the rules), but I don't see an
  essential reason why these are represented as DNS RRs.  And, (again
  as I believe everyone knows) it's not just ugly but also has some
  inherent flaws, such as that not all domain names can be represented
  due to length limitation.  In fact, not all existing implementations
  of RPZ-like feature use this form as the primary way of rule
  configuration (unbound is one example I happen to know of, and from
  a quick look knot resolver also seems to adopt its own configuration
  syntax).  Perhaps operators of these implementations use some
  conversion tools form the "standard" RPZ policies to its internal
  form, but that's obviously inconvenient.  Standardizing the spec
  more officially eventually leads to unified configuration (at least
  in concept) to eliminate the need for such a tool, but it would
  require changes to other existing implementations anyway.  Then it
  would be far better to develop a better form of policy
  representation from the beginning.

- If this is to be published as an IETF standard (even if
  "informational") and especially as a product of the dnsop wg, I
  believe it should contain more DNSSEC-related considerations.  The
  current situation is either
  + validly DNSSEC-signed responses bypass RPZ policies (when
'break-dnssec' is set to no), or
  + 'break-dnssec' is enabled, and it would currently confuse
validating stub resolvers
  As long as this wg hopes to see more such stub resolvers deployed
  (I'm assuming so), any of its protocol work should IMO help such
  deployment rather than hinder it.

- I know the above points are about to be dismissed with "these are
  out of scope of this doc; it just describes what is currently
  deployed".  And that's exactly another big concern of mine,
  especially because I heard the adoption of this draft would be
  similar to that of edns-client-subnet.  At that time several wg
  participants including myself raised unclear or ambiguous points of
  the spec, some of which were based on attempts of implementing it.
  Sadly, though, many of them were effectively silenced with the
  excuse of "not in scope".  Another excuse at that time was that
  there would be another standard truck doc to fix these issues, but,
  as quite predictably, people seem to have lost interest/energy once
  the RFC was published and there doesn't seem to be any attempt of
  revising the spec.  I've already sensed the same thing could happen
  for draft-vixie-dns-rpz from the adoption discussions on this list,
  and I don't like to see it actually happen.  To be clear, "really
  just describing what is currently deployed" is fine for me.  But my
  lesson from edns-client-subnet it can't well coexist with the intent
  of having more interoperable implementations.  If the intent is
  purely former, then it's better to 

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

[Philip Homburg]

>See the recent discovery that Heathrow Airport runs a
>MITM TLS server on torproject.org. Do we want them to run RPZ where they
>can disappear torproject.org alltogether? No. Do we want them to run RPZ
>to prevent travelers from getting malware installed? Yes.

Just my crystal ball:
1) If the traver's laptop/phone uses Heathrow Airport resolvers then Heathrow
   Airport can mount a denial of service on DNS. So it does not matter if the
   malware zone is signed or not. If Heathrow Airport modifies the reply the
   traveler will be protected.
2) It makes sense to do local validation with something like getdns. If such a
   local validating resolver notices that DNSSEC validation fails ("Roadblock
   Avoidance") it may contact auth. DNS servers directly.
3) Heathrow Airport can move to deep packet inspection and also block
   direct access to malware DNS.
4) DNS is not really private so Google may offer their DNS services over HTTPS.
5) Governments may force Google to block popular sites, so users switch to
   other DNS resolvers, again over HTTPS.

After step 5, any benign malware filtering options are probably lost.

In that sense I don't care that much about the more philosophical arguments
arguments against rpz. If you care about DNS, run a local DNSSEC validating
resolver that does roadblock avoidance and possibly falls back to 
TLS or HTTPS to some trusted resolver.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

On Jan 9, 2017, at 10:51 AM, Vernon Schryver  wrote:
> Note that the vast majority of clients of RPZ rewriting resolvers are
> stubs that don't do validation but trust header bits saying that a
> resolver operated by a third party did the validation.  I think that's
> wrong, evil, nasty, unethical, a Major Human Rights Issue, and blah
> de blah de blah, but it's also something no one seems willing and able
> to change.

*slow clap*

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: [Curdle] Protocol Action: 'EdDSA for DNSSEC' to Proposed Standard (draft-ietf-curdle-dnskey-eddsa-03.txt)

[Ondřej Surý]

Dear colleagues,

the EDDSA for DNSSEC have been approved by IESG.

Ondřej and Robert, co-editors


--- Forwarded message ---
From: The IESG 
Date: 9 January 2017 16:23:28
Subject: [Curdle] Protocol Action: 'EdDSA for DNSSEC' to Proposed Standard 
(draft-ietf-curdle-dnskey-eddsa-03.txt)

To: IETF-Announce 
CC: cur...@ietf.org, curdle-cha...@ietf.org, Daniel Migault 
, draft-ietf-curdle-dnskey-ed...@ietf.org, The 
IESG , stephen.farr...@cs.tcd.ie, rfc-edi...@rfc-editor.org


The IESG has approved the following document:
- 'EdDSA for DNSSEC'
 (draft-ietf-curdle-dnskey-eddsa-03.txt) as Proposed Standard

This document is the product of the CURves, Deprecating and a Little more
Encryption Working Group.

The IESG contact persons are Stephen Farrell and Kathleen Moriarty.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-curdle-dnskey-eddsa/





Technical Summary

 This document describes how to specify EdDSA keys and signatures in
 DNS Security (DNSSEC).  It uses the Edwards-curve Digital Security
 Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448.

Working Group Summary

 The definition of the signature format was straight forward as it already
 exists in DNSSEC. In addition the computation and verification of the
 signature is defined in [I-D.irtf-cfrg-eddsa].

 The only discussion was upon the use of using Ed25519ctx versus
 Ed25519, but the consensus was reached easily. The same discussion
 also occurred for draft-ietf-ipsecme-eddsa and draft-ietf-curdle-pkix
 with the same conclusion. The absence of context follows the
 recommendations of Section 10.3 of I-D.irtf-cfrg-eddsa and avoids
 unnecessarily complexity.


Document Quality

 The document has been reviewed carefully. Examples have been
 generated with prototypes. Although no implementations have
 been reported in the document, there are ongoing effort.

Personnel

 Document Shepherd: Daniel Migault,  AD: Stephen Farrell

___
Curdle mailing list
cur...@ietf.org
https://www.ietf.org/mailman/listinfo/curdle


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vernon Schryver]

> From: Ted Lemon 

> I think the main reason attackers won't sign =
> is that it's too much trouble, and provides no real benefit in the =
> presence of an effective RPZ block.

Yes, but there is a reason more important than RPZ for miscreants to
sign their attacks.  It is the same reason that plenty of spam is sent
with valid STARTTLS, DKIM, and/or SPF signatures and why spammers were
the first significant SPF publishers.  A large fraction of their targets
support the silly notion that authenticated strangers differ from other
strangers and that a certificate of authentication from a third party
is a bankable guarantee of virtue.

>   The question is, does it make sense to add code to the =
> validating resolver to detect and validate an RPZ block, so the user can =
> be informed that a block occurred, and who did it?   Would people =
> actually code this up? 

That's the rub.  RPZ has multiple independent interoperating
implementations, is widely deployed, and is in common use because the
customers of DNS recursive server implementators initially welcomed
it and now demand it.  Those customers are operators of DNS resolvers,
especially large operators who pay real money (as opposed to hot air)
for DNS server code, hire people to operate it, pay the secondary
bandwidth, training, bug and other costs, and pay for RPZ blacklists.

Where is the equivalent demand among resolver operators for doubling
the size of DNSSEC responses to contain both the original and the RPZ
rewritten rrsets including RRSIGs, and to pay the implied costs in
bugs, CPU cycles, bandwidth, training, security, etc?  People pay money
for code implementing what the draft describes, but as Ted Lemon asks,
who would pay for the suggested code in resolvers?  If it were free,
who would pay the costs of turning it on?
(You'd also need to convince RPZ blacklist providers to include RRSIGs
in their feeds, because you'd need signatures on rewritten responses.)

Such considerations are why so many users are behind resolvers that
validate DNSSEC but practically no domains are signed.  DNSSEC is a
good thing for operators of DNS clients, both resolvers and stubs, but
it is far more cost than benefit to operators of authority servers.
That's why we have the enduring, very discouraging picture at
http://scoreboard.verisignlabs.com/percent-trace.png
http://scoreboard.verisignlabs.com/

Such issues might also be why some of the most emphatic critics of RPZ in
this mailing list nevertheless send their critiques from unsigned domains.

Note that the vast majority of clients of RPZ rewriting resolvers are
stubs that don't do validation but trust header bits saying that a
resolver operated by a third party did the validation.  I think that's
wrong, evil, nasty, unethical, a Major Human Rights Issue, and blah
de blah de blah, but it's also something no one seems willing and able
to change.


Vernon Schryverv...@rhyolite.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Protocol Action: 'Managing DS records from parent via CDS/CDNSKEY' to Proposed Standard (draft-ietf-dnsop-maintain-ds-04.txt)

[The IESG]

The IESG has approved the following document:
- 'Managing DS records from parent via CDS/CDNSKEY'
  (draft-ietf-dnsop-maintain-ds-04.txt) as Proposed Standard

This document is the product of the Domain Name System Operations Working
Group.

The IESG contact persons are Benoit Claise and Joel Jaeggli.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/





Technical Summary

This document describes an in-band method for introducing and removing the 
Initial DNSSEC trust anchor between a parent and a child domain.  This is done 
by using the CDS/CDNSKEY DNS RR Types introduced in RFC7344. The document also 
attempts to produce reasonable initial acceptance policy.

This work is extending the work done in RFC7344, which was published as an 
Information document.  Time and experience has given the working group insight 
that the use and deployment of the CDS/CDNSKEY are useful in DNSSEC adoption.  
Therefore, with the publication of this document, the previous document should 
be elevated to Standards Track.

Working Group Summary

This working group was very supportive of this document, and discussion was 
centered around assisting the adoption of DNSSEC, but also the management of 
the DS Records. There was many constructive comments on the draft that have all 
been addressed.  The consensus was broad across the working group and the 
authors addressed all issues raised.

Document Quality

To be addressed in the interregnum, from the Genart review. 

This document intends to move RFC7344 from Informational to PS in place
(without republishing RFC7344. The intent to do so is buried at the end
of the document (the abstract doesn't mention it). The Last Call for the
document does not make it clear that _this_ document is elevating RFC7344.
(It at least mentions it, which is good, but the writeup about the elevation
can be read to say "we're considering this elevation somewhere else, keep it
in mind while evaluating this document").

There is no hint from the subject line that this is a call to bring RFC7344
onto the standards track. Unless there is some other communication effort
that I've missed on a quick search, I think it is very likely that most
of the IETF community outside the dnsop working group missed this intent.
I strongly encourge a last call focusing _specifically_ on moving RFC7344
to the standards track without republication.

My personal feedback on elevating RFC7344 without republishing is that it's
not the right thing to do. At the very least "Category: Informational"
appears in the document itself, and that will not change. If the IESG
decides to proceed with this as currently formulated, count me in the
deep rough. 

Personnel

Document Shepherd:   Tim Wicinski
Area Director:   Joel Jaggeli

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

On Jan 9, 2017, at 10:14 AM, Paul Wouters  wrote:
> Apple is getting ready to drop port 80 support. unsigned/unencrypted
> transports are dying. I hope we are moving to a word where DNS without
> DNSSEC will also be seen as bad. So yes, I am assuming in the future,
> attackers will have to sign DNS and that domains without DNSSEC are seen
> as "rogue domains that don't have clear audit trails".

It remains the case that most service providers at present appear to believe 
that PKI is enough, and they don't think DNSSEC is worth the trouble.   Like 
you, I look forward to the day when this is no longer true, although I don't 
look forward to the attack that changes peoples' minds about this.

>> I think this is actually not true: why is a DS record any more of an audit 
>> train than an NS record?
> 
> Because it proves ownership of the domain. My nohats.ca DS record cannot
> be modified by the UK ISPs forced to filter my domain. But they can
> spoof NS records. See the recent discovery that Heathrow Airport runs a
> MITM TLS server on torproject.org. Do we want them to run RPZ where they
> can disappear torproject.org alltogether? No. Do we want them to run RPZ
> to prevent travelers from getting malware installed? Yes.

We are talking at cross purposes.   We agree that the DS record proves 
ownership of the zone.   But it doesn't provide any more of an audit trail in 
terms of zone setup than does an NS record.   In terms of accurately 
identifying who set up the zone, it is completely useless.

>> Your point here, that in order for RPZ to function in the presence of 
>> widespread DNSSEC signing, there has to be some mechanism for authenticating 
>> RPZ answers _as_ RPZ answers, doesn't seem clearly true.   It
>> may be perfectly functional for RPZ answers to look like an attack.   But 
>> it's certainly worth considering, and has been talked about earlier in this 
>> thread.   The question is, does it make sense to add code
>> to the validating resolver to detect and validate an RPZ block, so the user 
>> can be informed that a block occurred, and who did it?   Would people 
>> actually code this up?   Would it be better or worse?
> 
> To me that is quite obvious "yes". If we allow the DNS protocol to
> randomly rewrite DNS, then why _do_ we have DNSSEC?

Again, not the point I was making.   Of course we want the resolver to do 
validation.   The question is, do we want the resolver to have code in it to 
validate who did the RPZ block.   I think this would be a really bad idea, and 
would be seriously damaging to human rights.

> Excellent! It means if the RPZ/DNS provider screws up, they are
> accountable. And they will properly maintain such systems that
> are golden opportunity for hackers to compromise. Also, the
> danger you are describing "I can make an attack look like protection to
> the end user" is exactly what the current RPZ spec already allows!
> I guess you really meant to say "a compromised RPZ system can unblock
> a malicious and previously blocked side". Well yes. You are describing
> a weakness, not a strength, of the RPZ solution.

You are thinking like a IETF geek.   The average end user will know nothing of 
this.   To them, it will simply be the case that their computer says "this is a 
malware site."   They will not see the audit trail.   It doesn't matter if the 
ACLU can detect the attack: they could have detected the attack without the 
signature, and most likely had a clear idea of who did it.

What matters is that we have no provided a way for malicious site operators to 
lie to end users, who will not be able to detect the lie.  To be clear, the lie 
is "I am authorized to block zones on your behalf."

> Just blocking the domain is "too much". And in my view that _is_ the
> human rights issue.

We disagree here.   I have seen way too many people screwed over by malware to 
think that preserving a perfect uncensored view of the DNS is more important 
than blocking malware.   As long as we can tell that we have been given a 
filtered response, I think we have the best possible compromise, and if sites 
are not willing to put in the effort to sign their zones, that is their problem.

> If we change this discussion and replace DNS and DNSSEC with BGP and
> RPKI, would you still think it is fine to allow random parties to
> change BGP announcements in a world of secure BGP so that users can
> be prevented to go to certain IP ranges?

If that IP range is being operated by a malware site or for example is going to 
redirect all of my traffic through a country that is sniffing my packets for 
intelligence purposes, then yes, it should be possible for the infrastructure 
to prevent the broken route from being installed, regardless of whether or not 
it has been signed.   This is the distinction between authentication and 
authorization that we all know so well: just because something is _authentic_ 
does not mean that it is authorized.

Taking that very clear 

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

[Paul Wouters]

On Mon, 9 Jan 2017, Ted Lemon wrote:


On Jan 8, 2017, at 11:49 PM, Paul Wouters  wrote:
  It is actually the other way around. If an end-node performs DNSSEC
  validation, it can only see RPZ modified answers as an attack. It is
  in the interest of RPZ to give such clients the confidence that the RPZ
  produced answer is not an attack but a handbreak action in the user's
  interest.


I think you missed what Barry was saying: you are correct that an end-node that 
performs DNSSEC validation will see RPZ on a domain that is signed as an 
attack.   The point Barry is making is that this only
matters if they sign their zones, and they won't, because doing so produces a 
clear audit trail leading back to them.


Apple is getting ready to drop port 80 support. unsigned/unencrypted
transports are dying. I hope we are moving to a word where DNS without
DNSSEC will also be seen as bad. So yes, I am assuming in the future,
attackers will have to sign DNS and that domains without DNSSEC are seen
as "rogue domains that don't have clear audit trails".


I think this is actually not true: why is a DS record any more of an audit 
train than an NS record?


Because it proves ownership of the domain. My nohats.ca DS record cannot
be modified by the UK ISPs forced to filter my domain. But they can
spoof NS records. See the recent discovery that Heathrow Airport runs a
MITM TLS server on torproject.org. Do we want them to run RPZ where they
can disappear torproject.org alltogether? No. Do we want them to run RPZ
to prevent travelers from getting malware installed? Yes.


  Nevertheless, let's be clear on what RPZ does and does not do.   I think the 
main reason attackers won't
sign is that it's too much trouble, and provides no real benefit in the 
presence of an effective RPZ block.


It's fine for "attackers" not to sign domains. That is not the point.


Your point here, that in order for RPZ to function in the presence of 
widespread DNSSEC signing, there has to be some mechanism for authenticating 
RPZ answers _as_ RPZ answers, doesn't seem clearly true.   It
may be perfectly functional for RPZ answers to look like an attack.   But it's 
certainly worth considering, and has been talked about earlier in this thread.  
 The question is, does it make sense to add code
to the validating resolver to detect and validate an RPZ block, so the user can 
be informed that a block occurred, and who did it?   Would people actually code 
this up?   Would it be better or worse?


To me that is quite obvious "yes". If we allow the DNS protocol to
randomly rewrite DNS, then why _do_ we have DNSSEC?


To me it seems like a bad idea: it's a larger attack surface, more complexity, 
a single point of attack: if I can compromise the RPZ keys, I can make an 
attack look like protection to the end user.  


Excellent! It means if the RPZ/DNS provider screws up, they are
accountable. And they will properly maintain such systems that
are golden opportunity for hackers to compromise. Also, the
danger you are describing "I can make an attack look like protection to
the end user" is exactly what the current RPZ spec already allows!
I guess you really meant to say "a compromised RPZ system can unblock
a malicious and previously blocked side". Well yes. You are describing
a weakness, not a strength, of the RPZ solution.


Ultimately, if we were to specify a solution for this, I think we doul actually 
be doing something harmful to human rights.   Isn't blocking the domain enough?


Just blocking the domain is "too much". And in my view that _is_ the
human rights issue.

If we change this discussion and replace DNS and DNSSEC with BGP and
RPKI, would you still think it is fine to allow random parties to
change BGP announcements in a world of secure BGP so that users can
be prevented to go to certain IP ranges?

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

On Jan 8, 2017, at 11:49 PM, Paul Wouters  wrote:
> It is actually the other way around. If an end-node performs DNSSEC
> validation, it can only see RPZ modified answers as an attack. It is
> in the interest of RPZ to give such clients the confidence that the RPZ
> produced answer is not an attack but a handbreak action in the user's
> interest.

I think you missed what Barry was saying: you are correct that an end-node that 
performs DNSSEC validation will see RPZ on a domain that is signed as an 
attack.   The point Barry is making is that this only matters if they sign 
their zones, and they won't, because doing so produces a clear audit trail 
leading back to them.

I think this is actually not true: why is a DS record any more of an audit 
train than an NS record?   Nevertheless, let's be clear on what RPZ does and 
does not do.   I think the main reason attackers won't sign is that it's too 
much trouble, and provides no real benefit in the presence of an effective RPZ 
block.

Your point here, that in order for RPZ to function in the presence of 
widespread DNSSEC signing, there has to be some mechanism for authenticating 
RPZ answers _as_ RPZ answers, doesn't seem clearly true.   It may be perfectly 
functional for RPZ answers to look like an attack.   But it's certainly worth 
considering, and has been talked about earlier in this thread.   The question 
is, does it make sense to add code to the validating resolver to detect and 
validate an RPZ block, so the user can be informed that a block occurred, and 
who did it?   Would people actually code this up?   Would it be better or worse?

To me it seems like a bad idea: it's a larger attack surface, more complexity, 
a single point of attack: if I can compromise the RPZ keys, I can make an 
attack look like protection to the end user.   Ultimately, if we were to 
specify a solution for this, I think we doul actually be doing something 
harmful to human rights.   Isn't blocking the domain enough?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-01.txt

[Ray Bellis]

I've submitted a -01 revision to address most of the feedback received
so far.

Ray

 Forwarded Message 
Subject: New Version Notification for draft-bellis-dnsop-xpf-01.txt
Date: Mon, 09 Jan 2017 04:41:53 -0800
From: internet-dra...@ietf.org
To: Ray Bellis 


A new version of I-D, draft-bellis-dnsop-xpf-01.txt
has been successfully submitted by Ray Bellis and posted to the
IETF repository.

Name:   draft-bellis-dnsop-xpf
Revision:   01
Title:  EDNS X-Proxied-For
Document date:  2017-01-09
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/internet-drafts/draft-bellis-dnsop-xpf-01.txt
Status: https://datatracker.ietf.org/doc/draft-bellis-dnsop-xpf/
Htmlized:   https://tools.ietf.org/html/draft-bellis-dnsop-xpf-01
Diff:   https://www.ietf.org/rfcdiff?url2=draft-bellis-dnsop-xpf-01

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop