> From: Paul Wouters <p...@nohats.ca>

> Some of us tried that and were told "that's not how RPZ works, we are
> not changing how RPZ works".

As I've repeatedly written, the purpose of the current draft is to
describe the current RPZ protocol.  The current draft and the protocol
it describes are not intended to and cannot prevent the specification
of other protocols, include protocols that might be called "RPZ."


> The only thing I asked for is tracability and accountability

As much tracability and accountability as can be hoped for is already
present with the RPZ SOA in the additional section.

>                                                               but not
> witholding DNSSEC information but by passing it along in a different
> section so that:
>
> - RPZ still works as it does now for existing users/providers
>
> - In the future RPZ filtering cannot be used as an out-of-the-box
>    involuntary censorship tool.
>
> - Accountability can be added by adding a different key of last
>    mile trust anchor.
>
> I'm interested in hearing technical reasons why this change cannot be
> done, ...

Paul Wouters has not made his idea clear to me (but let's keep talk
about it public at least as far as I'm concerned).  My best guesses about
it conclude that putting RRs that as far as DNS clients could tell
are irrelevant to the answer section into the authority section would
make some clients unhappy.  (Since it's not my idea, never mind that
I suspect that fewer DNS clients might break if apparently irrelevant
RRs were added to the additional section instead of the authority
section.)

On the other hand, Paul Woulters' ostensible goal is presumably that
the organizations responsible for any rewriting to be identifiable
during the investigations of problems and then held accountable.  They
are
  - men hidden in the middle using mechanisms other than RPZ, but it
     would be silly to expect them to step forward to be traced or held
     accountable.
  - the people running the recursive resolver with RPZ that sent
     the rewritten response, but the IP address of the recursive
     resolver already identifies them
  - the people that provided the policy zone containg the rule that
     used to modify the response, but the SOA already in the additional
     section points to them and also identifies the version of the rule.

But these guesses of mine about the idea are irrelevant.  Someone
should write a technical proposal for the idea and submit it as an I-D
or here as words that could be added to the current RPZ draft.  That
someone is not me; I told Paul Wouters in response to his private mail
on Dec 22:

] Please write whatever Internet Drafts that are needed, but please
] understand that I have no current interest in a new kind of RPZ.
] ...
] No, your proposals for new rtypes and shifting A and AAAA RRsets from
] the answer section to authority section might be good and reasonable
] in another context, but they are irrelevant to a description of RPZ
] as it currently exists.


Vernon Schryver    v...@rhyolite.com

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

Reply via email to