Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Brian Dickson <[e-mail]>]

On Wed, Feb 5, 2020 at 9:04 PM Adam Roach via Datatracker <[e-mail]>
wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-dprive-bcp-op-08: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks to the document authors, as well as everyone else who
> contributed to this document for all the work that went into
> its creation.  I have a handful of editorial suggestions that
> you may wish to take into account prior to publication. (I also
> have one request and one question in the list below.)
>
> I also support the first point of Alissa's discuss, and have
> elided several comments about Section 5.1.7 from my review
> below with the expectation that it will be removed.
>
> ---------------------------------------------------------------------------
>
> §1:
>
> >  Community insight [or judgment?] about operational practices can
> >  change quickly, and experience shows that a Best Current Practice
> >  (BCP) document about privacy and security is a point-in-time
> >  statement.  Readers are advised to seek out any errata or updates
> >  that apply to this document.
>
> RFC Errata are intended only to correct documents to reflect what
> the community believed they should have said at the time of publication
> (e.g., typographic errors, omissions in state machines), and not to
> provide updates to reflect later thinking. Please remove "errata or"
> from this sentence.
>
> ---------------------------------------------------------------------------
>
> §5.1.1:
>
> >  o  DNS-over-TLS [RFC7858] and [RFC8310].
> >
> >  o  DoH [RFC8484].
>
> Nit: For the sake of consistency, I would recommend either contracting
> both of these (e.g., "DoT" and "DoH"), or expanding them both.
>
> This same comment applies to the prose in section 5.1.2, as well
> as the titles of 5.1.3.1 and 5.1.3.2.
>
> ---------------------------------------------------------------------------
>
> §5.1.2.1:
>
> >  o  Mis-identification of a server by a client e.g. typos in URLs or
> >     authentication domain names [RFC8310].
>
> It's a bit unclear which kind of URLs this is referring to. Based on the
> proposed mitigation, I suspect it's talking about the use of URLs to
> configure a DNS server? Consider clarifying the URL's purpose in this
> text.
>
> ---------------------------------------------------------------------------
>
> §5.1.3.2:
>
> The use of EDNS(0) padding is conspicuous by its absence from this
> section. Is this intentional?
>
> ---------------------------------------------------------------------------
>
> §5.1.4:
>
> >  DNS Privacy Threats:
> >
> >  o  Users may be directed to bogus IP addresses for e.g. websites
> >     where they might reveal personal information to attackers.
>
> You might want to consider a different example than websites here. 80% of
> worldwide website traffic is secured by HTTPS, which means than any such
> attempts will be prevented by WebPKI certificate mismatches.
>
>
This argument ("any such attempts...") is flawed. (Apologies for the
directness; this is factual stuff.)

Here's why.

HTTPS certificate validation is based on the assumption that the client
connects to the actual IP of the server (aka "the real server").
The real server presents the certificate, and the TLS handshake proves that
the server possesses the private key of the certificate.

Loss of control of the private key is an issue ONLY if an attacker is able
to direct a client to an IP under control of the attacker.

The DNS component of WebPKI certificate validation is critical; it goes
"FQDN" -> DNS -> IP -> (TLS connection with SNI, get cert, validate cert
via handshake).
You can't connect to some random IP that hands you the cert you ask for,
you have to know you are contacting the legitimate web site first (via the
DNS to IP bits).

The issue isn't actually WebPKI *mismatches*, so much as it is about the
non-possession of the private key for the *real* certificate (or issuance
of another certificate matching the name).

If an attacker is able to obtain the private key, there is no difficulty in
obtaining the certificate itself (indeed, the real server serves it up, as
required by TLS).

The only roadblock to an attacker using a certificate after a private key
is obtained, is DNS.

Only DNSSEC can protect against cache poisoning attacks, by which an
attacker can direct clients to the IP under control of the attacker, and
succeed in impersonating the legitimate web site, which could be used to
elicit personal information from unwary users.
(Cache poisoning attacks aren't completely trivial, but they are many
orders of magnitude more feasible than brute strength attacks against
DNSSEC or WebPKI keys.)

So, the argument fails because it is reduced to the claim that "private
keys can't be obtained by attackers" (which cannot be guaranteed, clearly.)

Maybe some language that explains how/why the risk exists would help
clarify the threat?

Brian




> Notably, this means that the mitigation proposed is of diminished value
> for DNS servers that are used primarily or exclusively for resolving
> web server addresses, and the calculus of whether the overhead of
> implementing DNSSEC in such servers is worth the value it provides may
> vary radically from that which applies to general-purpose name resolvers.
> Given the fairly absolute language in the current mitigation section
> (only three mitigations use something as strong as "must"), it is
> probably worthwhile adding some text that acknowledges that the value
> of this mitigation varies depending on the applications that use the
> DNS service.
>
> ---------------------------------------------------------------------------
>
> §6.1.1:
>
> >  4.  Associated entities.  Declare any partners, third-party
> >      affiliations, or sources of funding.
>
> Having looked at a number of such disclosures recently, I've noticed
> that it has become fashionable to make such disclosures in the form
> of "<Corporation> may share information about our customers among
> the <corporation> family of companies," while eliding information
> that, for example, one such company is a user-tracking-based
> advertising network.
>
> So, if we're making suggestions for ideal policies, I might suggest
> something a bit more explicit, like:
>
>    4.  Associated entities.  Declare and explicitly enumerate any
>        partners, third-party affiliations, or sources of funding.
>
> ---------------------------------------------------------------------------
>
> §B.2:
>
> >  Since 2006, PowerDNS have included a de-identification tool
> >  Appendix B.2 with their PowerDNS product.
>
> There appears to be a spurious "Appendix B.2" on the second line of
> this paragraph.
>
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>