Re: [Add] Fwd: New Version Notification for draft-reddy-dprive-dprive-privacy-policy-00.txt

[Michael Richardson <[e-mail]>]

Paul Wouters <[e-mail]> wrote:
    >> We have
    >> published https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-00 that
    >> discusses a mechanism for the DNS server to communicate its
    >> cryptographically signed privacy policy information to a DNS
    >> client. By evaluating the DNS privacy policy and the signatory, the
    >> DNS client can choose to  select or avoid a DoT/DoH server if it
    >> doesn't comply with the client's privacy expectations.

    > Section 10 Security Considerations describes well why I think this is
    > not a good idea. Publishing a privacy policy in a computer consumable
    > way has no relationship to the actual DNS server's privacy policy used.

    > This is not a technical wire problem to solve with an RFC. It is a
    > social-economic issue. Can we trust vendor X? And vendor X making
    > claims in JSON about this isn't useful from a technical point of view,
    > no matter how or where and with what such statements are (self)signed.

Of course vendor X probably can't say anything trust-worthy about itself.
Depending upon one's relationship with X one may be in a position to believe
statements from it and take appropriate action.  For instance, if X is your
employer and your BYOD is paying attention to this statement, then you might
decide to refrain from visiting NSFW site FOO. Or decide to use LTE.

But, we anticipate that vendor X would have the implementation of their
policy reviewed regularly by some other endorser Y.  We have been in contact
with a few entities that have done these kinds of reviews of DoT systems in
the past, but at this point I don't think we have a shared understanding of
goals yet. 

Section 6...

   The PAT is cryptographically signed by the domain hosting the DNS
   server and OPTIONALLY BY A THIRD PARTY WHO PERFORMED PRIVACY AND
   SECURITY AUDIT OF THE DNS SERVER.  The privacy policy information
   will be attested using "Organization Validation" (OV) or "Extended
   Validation" (EV) certificates to avoid bad actors taking advantage of
   this mechanism to advertise DNS-over-TLS and DNS-over-HTTPS servers
   for illegitimate and fraudulent purposes meant to trick DNS clients
   into believing that they are using a legitimate DNS-over-TLS or DNS-
   over-HTTPS server hosted to provide privacy for DNS transactions.
   Alternatively, the DNS client will have to be configured to trust the
   leaf of the signer of the PAT object.  That is, trust of the signer
   MUST NOT be determined by validating the signer via the OS or browser
   trust chain because that would allow any arbitrary entity to operate
   a DNS server and assert any sort of privacy policy.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [