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

From: Adam Roach via Datatracker <[email-masked]>
Date: Wed, 05 Feb 2020 21:04:32 -0800

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.

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.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 5 Feb 2020 21:35:46 -0800

> attempts will be prevented by WebPKI certificate mismatches.

While I agree that this example could use a caveat, I do not believe WebPKI
certificate mismatches will always prevent these attempts.

thanks,
Rob

---

From: Brian Dickson <[email-masked]>
Date: Wed, 5 Feb 2020 21:55:09 -0800

> https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/
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

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 6 Feb 2020 09:08:37 -0600

On 2/5/20 23:55, Brian Dickson wrote:
> 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).

Sure, and I'm certain that whatever material the legitimate zone 
administrator uses to authenticate changes to the DNS zone can also be 
exfiltrated. Security relies on administrative hygiene as much as it 
does technical mechanisms.

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

Or BGP hijacking, which is on the same order of magnitude of difficulty 
as what you posit.

> 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.
> 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.)
>

I don't think that's useful. All security systems can be defeated, and 
it's probably not worth going into the details of the various Achilles' 
heels of the name resolution, routing, and application protocols involved.

At a general level, the issue I am highlighting is that the cost/benefit 
analysis changes dramatically when there is already a system in place 
(flawed, as all security systems are) to protect against arbitrary 
impersonation as compared to situations when there is not, and that it 
would be more realistic for the document to accurately represent that.

For the specific example chosen, it's been made pretty clear over the 
years that at least the clients for the specific service you cite have 
no interest in incurring this additional cost. If that's the working 
group consensus, then I have no interest in over-riding it. But ignoring 
operational realities seems kind of ivory tower-ish, which feels like 
the kind of thing that undermines the general credibility of the rest of 
the document.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 6 Feb 2020 11:31:07 -0600

On 2/6/20 09:08, Adam Roach wrote:
> group consensus, then I have no interest in over-riding it. But 
> ignoring operational realities seems kind of ivory tower-ish, which 
> feels like the kind of thing that undermines the general credibility 
> of the rest of the document.
>

I realize that my editing made one of the pronoun antecedents here go 
away. The second sentence should have said something more like "If 
keeping the current text is the working group consensus..."

/a

---

From: Brian Dickson <[email-masked]>
Date: Thu, 6 Feb 2020 09:57:06 -0800

> > of the rest of the document.

Could you please be more specific?

When you say "for the specific service", do you mean DNSSEC?

And do you mean the signing of DNS zones using DNSSEC, when you refer to
clients of that service?

Perhaps you missed my microphone comments at the last IETF?

Specifically that GoDaddy will be turning on DNSSEC for the vast majority
of its DNS hosting customers?

This represents about 40% of the DNS zones on the Internet.
(The exact time frame is not set in stone, but we expect this to be done in
the first half of 2020.)

Given that this significantly alters the calculus, I don't think that is a
good enough reason to object in and of itself anymore.

The other aspect of this is the asymmetry involved in the defenses against
impersonation:

   - The choice to sign a DNS zone is under control of the zone owner
   - The choice to deploy RPKI on routes (to protect against BGP hijacking)
   is under control of the IP prefix holder
   - Both methods rely on third parties to cooperate to achieve the
   protections offered
   - RPKI routing filters are now widely deployed, and RPKI registrations
   are substantial
   - The remaining issue is DNSSEC validation; many (most?) of the public
   recursive operators do this already

The logic should be, defend against all feasible attacks, rather than
justifying the non-defense in one area (DNSSEC for DNS) based on the
assertion that another area is not being defended (RPKI for BGP).

Brian

---

From: Adam Roach <[email-masked]>
Date: Thu, 6 Feb 2020 12:22:04 -0600

Top-posting because I agree with the facts as you present them. I just 
reach a different conclusion based on these facts. To be clear, I think 
a belt-and-suspenders approach is generally preferable. I am merely 
suggesting that the "must" statement I cite may be stronger than is 
actually advisable given that such an approach is merely a small 
increment of security for protocols that are otherwise secured (e.g., 
HTTP, which is the example the document chooses), rather than the sole 
defense, as may be the case with other protocols.

My top-line suggestion here is to choose a different example than HTTP.

Secondary to that is a suggestion that the "must" statement really only 
makes sense when it is a sole counter-measure, and that a softer 
recommendation ("should") makes more sense otherwise.

These are non-blocking comments, so I'm going to reiterate that the WG 
can ignore them -- I just wanted to make sure they were considered. It 
would be nice to hear from other folks on the topic as well.

/a

On 2/6/20 11:57, Brian Dickson wrote:
>
>
> On Thu, Feb 6, 2020 at 9:31 AM Adam Roach <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> And do you mean the signing of DNS zones using DNSSEC, when you refer 
> to clients of that service?
>
> Specifically that GoDaddy will be turning on DNSSEC for the vast 
> majority of its DNS hosting customers?
>
> (The exact time frame is not set in stone, but we expect this to be 
> done in the first half of 2020.)
>
> Given that this significantly alters the calculus, I don't think that 
> is a good enough reason to object in and of itself anymore.
>
> The other aspect of this is the asymmetry involved in the defenses 
> against impersonation:
>
>   * The choice to sign a DNS zone is under control of the zone owner
>   * The choice to deploy RPKI on routes (to protect against BGP
>     hijacking) is under control of the IP prefix holder
>   * Both methods rely on third parties to cooperate to achieve the
>     protections offered
>   * RPKI routing filters are now widely deployed, and RPKI
>     registrations are substantial
>   * The remaining issue is DNSSEC validation; many (most?) of the
>     public recursive operators do this already
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 6 Feb 2020 11:22:15 -0800

Thanks. I am just looking at this text, and I think it's inappropriate. To
recap something I seem to be saying a lot lately, the Internet Threat Model
assumes a Dolev-Yao-style attacker who controls the network between the
client and the server. TLS is designed to be secure in this environment,
and while the WebPKi is imperfect, suggesting that compromise of local DNS
lookups leads to compromise of user data seems exaggerated, at least in the
case of Web traffic.

-Ekr

On Thu, Feb 6, 2020 at 10:22 AM Adam Roach <[email-masked]> wrote:

> reach a different conclusion based on these facts. To be clear, I think a
> belt-and-suspenders approach is generally preferable. I am merely
> actually advisable given that such an approach is merely a small increment
> of security for protocols that are otherwise secured (e.g., HTTP, which is
> the example the document chooses), rather than the sole defense, as may be
> the case with other protocols.
>
> These are non-blocking comments, so I'm going to reiterate that the WG can
> ignore them -- I just wanted to make sure they were considered. It would be
> nice to hear from other folks on the topic as well.
>
> /a
>
> (The exact time frame is not set in stone, but we expect this to be done
> in the first half of 2020.)
>
>    - The choice to deploy RPKI on routes (to protect against BGP

---

From: Brian Dickson <[email-masked]>
Date: Thu, 6 Feb 2020 12:03:53 -0800

Top-top-top reply:
The Internet Threat Model you are using for web client-server is fine.
However, for DNS, that is the wrong threat model, for several reasons.

   - The threat for DNS cache poisoning is recursive-to-authoritative, not
   client-recursive(resolver)
   - The DNS path will not generally be related to the data path, and for
   any parent zone, almost certainly will be totally unrelated
   - DNS recursive-to-authoritative is UDP
   - UDP DNS does not require that the attacker be on-path
   - Compromise of DNS caches via poisoning (by potentially off-path
   attackers) leading to compromise of user data is not exaggerated.
   - The compromise risk is per-cache, as well as per-authority-server
   and/or per-DNS record.

I haven't written up the details of the more effective cache poisoning
attacks, but have been sharing summary information for several years now.
(The underlying issue is IP fragmentation of UDP packets. This is one of
the contributing factors that the DNS Flag Day for 2020 will include
recommendations/requirements to not fragment.)

I'd be willing to write up those more effective attacks, including a PoC,
but that won't likely happen for a few months.

Brian

On Thu, Feb 6, 2020 at 11:22 AM Eric Rescorla <[email-masked]> wrote:

>> Given that this significantly alters the calculus, I don't think that is
>> a good enough reason to object in and of itself anymore.
>>
>>    - RPKI routing filters are now widely deployed, and RPKI
>>    - The remaining issue is DNSSEC validation; many (most?) of the

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 6 Feb 2020 12:08:13 -0800

On Thu, Feb 6, 2020 at 12:04 PM Brian Dickson <[email-masked]>
wrote:

>    - The threat for DNS cache poisoning is recursive-to-authoritative,
>    not client-recursive(resolver)
First, all of these are just consequences of the 3552 "attacker completely
controls the network" threat model.

Second, the text in question is about the effect of attacks on DNS on the
Web "Users may be directed to bogus IP addresses for e.g. websites where
they might reveal personal information to attackers."

-Ekr

>> Thanks. I am just looking at this text, and I think it's inappropriate.
>> To recap something I seem to be saying a lot lately, the Internet Threat
>> Model assumes a Dolev-Yao-style attacker who controls the network between
>> the client and the server. TLS is designed to be secure in this
>> environment, and while the WebPKi is imperfect, suggesting that compromise
>> of local DNS lookups leads to compromise of user data seems exaggerated, at
>> least in the case of Web traffic.
>>
>> -Ekr
>>
>>

---

From: Rob Sayre <[email-masked]>
Date: Thu, 6 Feb 2020 12:23:22 -0800

> they might reveal personal information to attackers."

I agree that the WebPKI can help here, but it cannot be viewed as a solid
remediation. For one, browsers will still connect to non-HTTPS sites. Here
is a large concrete example of an attack the matches what the draft
describes:

https://www.zdnet.com/article/brazil-is-at-the-forefront-of-a-new-type-of-router-attack/

Secondly, root certificate stores are not consistent. One example:

https://www.cs.umd.edu/class/fall2017/cmsc818O/papers/tangled-mass.pdf

Thirdly, it's not clear that misrouted traffic (either via DNS or lower
level ways like BGP) won't encounter seemingly-legitimate certificates,
because the number of people that can issue them is so large.

I know Ekr knows all of this, and I do think that text on bogus IP
addresses needs a caveat. But I'm not sure the text in the draft is totally
misguided.

thanks,
Rob

---

From: Brian Dickson <[email-masked]>
Date: Thu, 6 Feb 2020 12:44:37 -0800

On Thu, Feb 6, 2020 at 12:08 PM Eric Rescorla <[email-masked]> wrote:

>
>
> On Thu, Feb 6, 2020 at 12:04 PM Brian Dickson <
> [email-masked]> wrote:
>
>> Top-top-top reply:
>>    - The DNS path will not generally be related to the data path, and
>>    for any parent zone, almost certainly will be totally unrelated

Sorry, I'm not clear on what this statement means in this context, or what
the implication of this should be inferred as being.

Are you saying:

   - It should be assumed (per the threat model) that any/every attacker
   completely controls every network segment everywhere?
   - or, that only attackers who DO control some specific network segment
   are a threat?

These have vastly different implications, clearly.
If the first one is the case, are you conceding the precondition, that
attackers can poison DNS caches arbitrarily, by manipulating all DNS
traffic? If so, that argues in favor of DNSSEC validation by the resolver
in all cases, as that is the only way the attack can be blocked.

If the second one is the case, the bullet points you quote, contradict that
assertion. Specifically, that off-path attackers do not need to control any
network segment (let alone all network segments), to successfully poison a
DNS cache. This also argues in favor of DNSSEC validation.

If you mean something else, could you explain what you mean?

> they might reveal personal information to attackers."
Correct, and I don't see anything you say here refuting the concern over
DNS cache poisoning attacks, which result in bogus IP addresses directing
users to malicious servers, etc.

If users are sent to the wrong IP address, this substantially weakens the
argument that WebPKI is sufficient protection.

Why are CLR and/or OCSP needed, if not to respond to compromised
certificates (meaning leaked private keys)?

Am I missing something about WebPKI, beyond the private key proof of
possession model?
(Everything else about WebPKI is about validating the requestor's authority
and identity, but that is all orthogonal to key control.)

A web server using a compromised key is only ever going to be visible to a
(potential) victim, and never to third parties including the legitimate
certificate holder, except incidentally to operation of the rogue server.

Brian

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 6 Feb 2020 12:51:21 -0800

On Thu, Feb 6, 2020 at 12:44 PM Brian Dickson <[email-masked]>
wrote:

>> First, all of these are just consequences of the 3552 "attacker
>> completely controls the network" threat model.
>>
>
> If the second one is the case, the bullet points you quote, contradict
> that assertion. Specifically, that off-path attackers do not need to
> control any network segment (let alone all network segments), to
> successfully poison a DNS cache. This also argues in favor of DNSSEC
> validation.
>

I'm saying that TLS assumes a Dolev-Yao threat model in which the attacker
is on-path between the client and the server and therefore can manipulate
the traffic regardless of whether the client correctly knows the server's
IP.

-Ekr

> (Everything else about WebPKI is about validating the requestor's
> authority and identity, but that is all orthogonal to key control.)
>
>>> I'd be willing to write up those more effective attacks, including a
>>> PoC, but that won't likely happen for a few months.
>>>
>>> Brian
>>>
>>>>> Secondary to that is a suggestion that the "must" statement really
>>>>> only makes sense when it is a sole counter-measure, and that a softer

---

From: Adam Roach <[email-masked]>
Date: Thu, 6 Feb 2020 14:57:53 -0600

This is really getting off into the weeds.

Brian -- a lot of your assertions seem to be predicated on some 
underlying assumption that WebPKI is worthless or nearly worthless. Can 
you clarify whether that's your stance?

/a

On 2/6/20 14:44, Brian Dickson wrote:
>
>
> On Thu, Feb 6, 2020 at 12:08 PM Eric Rescorla <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>     On Thu, Feb 6, 2020 at 12:04 PM Brian Dickson
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Top-top-top reply:
>           * The threat for DNS cache poisoning is
>             recursive-to-authoritative, not client-recursive(resolver)
>           * The DNS path will not generally be related to the data
>             path, and for any parent zone, almost certainly will be
>             totally unrelated
>           * DNS recursive-to-authoritative is UDP
>           * UDP DNS does not require that the attacker be on-path
>           * Compromise of DNS caches via poisoning (by potentially
>             off-path attackers) leading to compromise of user data is
>             not exaggerated.
>           * The compromise risk is per-cache, as well as
>             per-authority-server and/or per-DNS record.
>
>
> Sorry, I'm not clear on what this statement means in this context, or 
> what the implication of this should be inferred as being.
>
> Are you saying:
>
>   * It should be assumed (per the threat model) that any/every
>     attacker completely controls every network segment everywhere?
>   * or, that only attackers who DO control some specific network
>     segment are a threat?
>
> traffic? If so, that argues in favor of DNSSEC validation by the 
> resolver in all cases, as that is the only way the attack can be blocked.
>
>     Second, the text in question is about the effect of attacks on DNS
>     on the Web "Users may be directed to bogus IP addresses for e.g.
>     websites where they might reveal personal information to attackers."
>
>
> Correct, and I don't see anything you say here refuting the concern 
> over DNS cache poisoning attacks, which result in bogus IP addresses 
> directing users to malicious servers, etc.
>
> If users are sent to the wrong IP address, this substantially weakens 
> the argument that WebPKI is sufficient protection.
>
> A web server using a compromised key is only ever going to be visible 
> to a (potential) victim, and never to third parties including the 
> legitimate certificate holder, except incidentally to operation of the 
> rogue server.
>
> Brian
>
>     -Ekr
>
>
>         I haven't written up the details of the more effective cache
>         poisoning attacks, but have been sharing summary information
>         for several years now.
>         (The underlying issue is IP fragmentation of UDP packets. This
>         is one of the contributing factors that the DNS Flag Day for
>         2020 will include recommendations/requirements to not fragment.)
>
>         I'd be willing to write up those more effective attacks,
>         including a PoC, but that won't likely happen for a few months.
>
>         Brian
>
>         On Thu, Feb 6, 2020 at 11:22 AM Eric Rescorla <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             Thanks. I am just looking at this text, and I think it's
>             inappropriate. To recap something I seem to be saying a
>             lot lately, the Internet Threat Model assumes a
>             Dolev-Yao-style attacker who controls the network between
>             the client and the server. TLS is designed to be secure in
>             this environment, and while the WebPKi is imperfect,
>             suggesting that compromise of local DNS lookups leads to
>             compromise of user data seems exaggerated, at least in the
>             case of Web traffic.
>
>             -Ekr
>
>
>             On Thu, Feb 6, 2020 at 10:22 AM Adam Roach
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>                 Top-posting because I agree with the facts as you
>                 present them. I just reach a different conclusion
>                 based on these facts. To be clear, I think a
>                 belt-and-suspenders approach is generally preferable.
>                 I am merely suggesting that the "must" statement I
>                 cite may be stronger than is actually advisable given
>                 that such an approach is merely a small increment of
>                 security for protocols that are otherwise secured
>                 (e.g., HTTP, which is the example the document
>                 chooses), rather than the sole defense, as may be the
>                 case with other protocols.
>
>                 Secondary to that is a suggestion that the "must"
>                 statement really only makes sense when it is a sole
>                 counter-measure, and that a softer recommendation
>                 ("should") makes more sense otherwise.
>
>                 These are non-blocking comments, so I'm going to
>                 reiterate that the WG can ignore them -- I just wanted
>                 to make sure they were considered. It would be nice to
>                 hear from other folks on the topic as well.
>
>                 /a
>
>>                 On Thu, Feb 6, 2020 at 9:31 AM Adam Roach
>>                 <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>                 And do you mean the signing of DNS zones using
>>                 DNSSEC, when you refer to clients of that service?
>>
>>                 Specifically that GoDaddy will be turning on DNSSEC
>>                 for the vast majority of its DNS hosting customers?
>>
>>                 (The exact time frame is not set in stone, but we
>>                 expect this to be done in the first half of 2020.)
>>
>>                 Given that this significantly alters the calculus, I
>>                 don't think that is a good enough reason to object in
>>                 and of itself anymore.
>>
>>                 The other aspect of this is the asymmetry involved in
>>                 the defenses against impersonation:
>>
>>                   * The choice to deploy RPKI on routes (to protect
>>                     against BGP hijacking) is under control of the IP
>>                     prefix holder
>>                   * Both methods rely on third parties to cooperate
>>                     to achieve the protections offered
>>                   * RPKI routing filters are now widely deployed, and
>>                     RPKI registrations are substantial
>>                   * The remaining issue is DNSSEC validation; many
>>                     (most?) of the public recursive operators do this
>>                     already
>>
>>                 The logic should be, defend against all feasible
>>                 attacks, rather than justifying the non-defense in
>>                 one area (DNSSEC for DNS) based on the assertion that
>>                 another area is not being defended (RPKI for BGP).
>>
>>                 Brian
>>
>>
>                 [email-masked] <mailto:[email-masked]>

---

From: Brian Dickson <[email-masked]>
Date: Thu, 6 Feb 2020 13:10:44 -0800

On Thu, Feb 6, 2020 at 12:58 PM Adam Roach <[email-masked]> wrote:

> Brian -- a lot of your assertions seem to be predicated on some underlying
> assumption that WebPKI is worthless or nearly worthless. Can you clarify
> whether that's your stance?
>

Sure, that's easy.

WebPKI is valuable, for web traffic. Its strength is highly dependent on
ensuring the client is connecting to the correct server, i.e. that DNS is
not altered.
WebPKI is potentially able to be made much stronger by the addition of DANE
TLSA records, so that the specific choice of CA can be securely verified
(preventing the malicious issuance of competing certs).
WebPKI is also made much stronger by DANE TLSA, in that unpublishing a TLSA
record is more reliable for asserting the invalidity of a certificate than
OCSP or CRL methodologies. The latter, as I understand it, fail "unsafe",
where failure to contact the CRL or OCSP server does not block the web
connection. If web browsers implemented TLSA validation and failed "safe",
the impact of blocking DNS traffic for a domain would be the same, whether
for blocking the TLSA record or the A/AAAA records - it would be a denial
of service, but would also be mitigated by the presence of DNS caching.

I'm highly in favor of WebPKI, and also in favor of improving the
protections against some fundamental weaknesses that currently exist, by
using already-defined IETF specifications (DANE).

In fact, I'll be an internal advocate for publishing TLSA records for CA
certs for customer TLS certs (type 0 TLSA records) once we have ubiquitous
DNSSEC signing. (TLSA requires DNSSEC).

In other words, I advocate WebPKI + DNSSEC + TLSA, and that is the exact
opposite of WebPKI being worthless or nearly worthless.
I'm also an advocate of RPKI (BGP resource pki to prevent route hijacking)
and RPKI ROA validation, and BGP route-leak-detection-mitigation (I'm a
co-author of that in the GROW working group).

Brian

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 6 Feb 2020 17:14:11 -0800

> the traffic regardless of whether the client correctly knows the server's

TLS also punts the key-management story to be out of scope.
We have a lot of worked examples of the Web PKI failing (and also have lots
of people working really hard to get it to improve, which I greatly
appreciate), but given that the recursive has no way of knowing what the
DNS client is planning to do (and that some ~20% of web traffic does not
use TLS), it's hard for me to argue that this document is making the wrong
recommendation about DNSSEC validation.

-Ben

---

From: Rob Sayre <[email-masked]>
Date: Thu, 6 Feb 2020 20:07:02 -0800

> recommendation about DNSSEC validation.

Maybe it would be more diplomatic for the document to state that additional
validation might help. DNSSEC is one existing mechanism, but other options
like PSKs of various types (e.g. PAKE) exist.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 6 Feb 2020 21:38:41 -0800

On Thu, Feb 6, 2020 at 5:14 PM Benjamin Kaduk <[email-masked]> wrote:

> what
> resolver
> appreciate),

I hear this argument a lot, but those examples are orders of magnitude
lower than the fraction of domains which aren't even DNSSEC protected.

> but given that the recursive has no way of knowing what the

The question at hand is not about whether it ought to recommend DNSSEC
validation but rather whether the text around that, which implies that
failure to do so has a high risk of sending your sensitive *web* traffic to
the attacker, is accurate given the high fraction of Web traffic that is
protected with TLS and the likely even higher fraction of sensitive traffic
that is.

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Thu, 6 Feb 2020 21:54:03 -0800

On Thu, Feb 6, 2020 at 9:39 PM Eric Rescorla <[email-masked]> wrote:

> that is..

This is not the best argument, since the interaction of DNS and subsequent
TLS traffic is not defined. An example is <
https://www.zdnet.com/article/brazil-is-at-the-forefront-of-a-new-type-of-router-attack/
>.

Talking about a "high fraction" of traffic is not very convincing, since
most traffic is obviously not subject to these attacks.

thanks,
Rob

---

From: Brian Dickson <[email-masked]>
Date: Fri, 7 Feb 2020 00:18:55 -0800

> protected with TLS and the likely even higher fraction of sensitive traffic

The issue around implied risk, is a longitudinal one.

For sake of argument, let's assume 100.0% of web traffic is TLS protected.
Let's also assume that of the privacy resolver operators, there is at least
one that does not do DNSSEC.

If an attacker obtains the private key for *some* certificate for a web
site, what is the risk for the customers of the two groups of resolver
operators?

The risk for the DNSSEC validating operators' clients is zero if the web
site is in a DNSSEC signed domain.
The risk for the non-DNSSEC validating operators' clients is non-zero if
the web site is in a DNSSEC signed domain.

The risk depends on the ability of the attacker to poison the cache.
The validating resolver cannot be poisoned if the zone is signed.
The non-validating resolver can be poisoned even if the zone is signed.

The fact of non-DNSSEC validation is very likely known, particularly given
the public nature of privacy resolver operators, and trivial to confirm
directly by using them as a resolver.
The non-validating operators will definitely be a target for such an
attacker.

It doesn't particularly matter which certificate is compromised, in
principal; the question is whether the web traffic for that site can be
compromised. If the DNS poisoning succeeds, the answer is yes.

An attacker is unlikely to do the poisoning attack unless there is a
benefit to doing so, such as already possessing the private key.

I don't have any particular knowledge of how often keys leak.

I do have a pretty good idea how easy it is to poison a resolver.

It is generally only a factor of, at most, bandwidth and the ability to
send queries as a resolver client.
And unlike the typical ISP or enterprise or small network, the resolvers
here have to be open for use to anyone.
This makes them particularly vulnerable to the conditions that facilitate
poisoning.
And it is precisely this that make the case for a MUST rather than a SHOULD.

Brian

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 7 Feb 2020 10:08:49 +0000

DNS poisoning is used as an attack vector even with TLS where users can potentially ignore/accept fake certificates and lost $, for instance see https://www.theregister.co.uk/2018/04/24/myetherwallet_dns_hijack/.

-Tiru

From: dns-privacy <[email-masked]> On Behalf Of Brian Dickson
Sent: Friday, February 7, 2020 1:49 PM
To: Eric Rescorla <[email-masked]>
Cc: Tim Wicinski <[email-masked]>; Adam Roach <[email-masked]>; Benjamin Kaduk <[email-masked]>; [email-masked]; [email-masked]; DNS Privacy Working Group <[email-masked]>; The IESG <[email-masked]>
Subject: Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
On Thu, Feb 6, 2020 at 9:39 PM Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Feb 6, 2020 at 5:14 PM Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> wrote:

The question at hand is not about whether it ought to recommend DNSSEC validation but rather whether the text around that, which implies that failure to do so has a high risk of sending your sensitive *web* traffic to the attacker, is accurate given the high fraction of Web traffic that is protected with TLS and the likely even higher fraction of sensitive traffic that is..

For sake of argument, let's assume 100.0% of web traffic is TLS protected.
Let's also assume that of the privacy resolver operators, there is at least one that does not do DNSSEC.

If an attacker obtains the private key for *some* certificate for a web site, what is the risk for the customers of the two groups of resolver operators?

The risk for the DNSSEC validating operators' clients is zero if the web site is in a DNSSEC signed domain.
The risk for the non-DNSSEC validating operators' clients is non-zero if the web site is in a DNSSEC signed domain.

The fact of non-DNSSEC validation is very likely known, particularly given the public nature of privacy resolver operators, and trivial to confirm directly by using them as a resolver.
The non-validating operators will definitely be a target for such an attacker.

It doesn't particularly matter which certificate is compromised, in principal; the question is whether the web traffic for that site can be compromised. If the DNS poisoning succeeds, the answer is yes.

An attacker is unlikely to do the poisoning attack unless there is a benefit to doing so, such as already possessing the private key.

It is generally only a factor of, at most, bandwidth and the ability to send queries as a resolver client.
And unlike the typical ISP or enterprise or small network, the resolvers here have to be open for use to anyone.
This makes them particularly vulnerable to the conditions that facilitate poisoning.
And it is precisely this that make the case for a MUST rather than a SHOULD.

Brian

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 7 Feb 2020 02:16:55 -0800

> the web site is in a DNSSEC signed domain.

I don't think we're getting anywhere particularly useful here, so I'll
probably make this my last response unless something particularly new
emerges.

The ability of an attacker to compromise a given connection depends on (1)
the ability to intercept the wire traffic and (2) the ability to compromise
the TLS connection. A successful attack (as a general matter) requires both
of these abilities. Because there are a number of environments in which the
ability to intercept wire traffic is trivial (e.g., an open WiFi hotspot)
TLS is designed under the assumption that the attacker has ability (1), in
which case, the security rests on ability (2), which it might achieve in a
number of ways, with key compromise being one of them.

It is certainly true that defense in depth is a good thing and that
measures which strengthen the user's wire traffic against interception by
the attacker will generally increase security. However, it is neither the
case that DNSSEC validation is sufficient to guarantee this protection
(contra your statement above state above) nor that in the absence of DNSSEC
validation compromise of the user's data is a generally anticipated
consequence (as implied by the text in question). It is not sufficient
because (1) the attacker may be on-path, in which case it is irrelevant
whether the client is able to resolve the right IP address or (2) the
DNSSEC signing key is itself uncompromised [usually we just assume that
keys are secure, but given that the scenario you are positing for WebPKI
failure is key compromise, DNSSEC signing key compromise needs also to be
in scope]. It is not necessary because, as has been noted already, we
generally assume that the WebPKI provides a reasonable level of security on
its own, although, as Adam observes, nothing is perfect.

-Ekr

---

From: Brian Dickson <[email-masked]>
Date: Fri, 7 Feb 2020 03:33:54 -0800

Top reply to keep it brief:
WebPKI requires online keys. It is a core part of TLS; encrypting something  with the private key is the critical security function of the handshake.
DNSSEC does not require online keys. This is due to the communication model of DNS: publication. Once published, DNSSEC doesn’t care how you obtain the records. The validation depends only on public keys.
(There are instances where on-the-fly DNSSEC signing is done, of course; the general practice for how that is done is with HSM.)

Zone signing is generally done offline, and in many cases is done with an HSM. Keys that aren’t online are by their nature protected from compromise.

Some TLS keys may be protected with similar mechanisms, but it is nowhere near the percentage of DNSSEC.

DNSSEC validation is complete protection against an attacker who is not on-path.

Brian

Sent from my iPhone

> On Feb 7, 2020, at 2:17 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> 
>> On Fri, Feb 7, 2020 at 12:19 AM Brian Dickson <[email-masked]> wrote:
>> 
>> 
>>> The question at hand is not about whether it ought to recommend DNSSEC validation but rather whether the text around that, which implies that failure to do so has a high risk of sending your sensitive *web* traffic to the attacker, is accurate given the high fraction of Web traffic that is protected with TLS and the likely even higher fraction of sensitive traffic that is.
>> 
> I don't think we're getting anywhere particularly useful here, so I'll probably make this my last response unless something particularly new emerges.
> 
> The ability of an attacker to compromise a given connection depends on (1) the ability to intercept the wire traffic and (2) the ability to compromise the TLS connection. A successful attack (as a general matter) requires both of these abilities. Because there are a number of environments in which the ability to intercept wire traffic is trivial (e.g., an open WiFi hotspot) TLS is designed under the assumption that the attacker has ability (1), in which case, the security rests on ability (2), which it might achieve in a number of ways, with key compromise being one of them.
> 
> It is certainly true that defense in depth is a good thing and that measures which strengthen the user's wire traffic against interception by the attacker will generally increase security. However, it is neither the case that DNSSEC validation is sufficient to guarantee this protection (contra your statement above state above) nor that in the absence of DNSSEC validation compromise of the user's data is a generally anticipated consequence (as implied by the text in question). It is not sufficient because (1) the attacker may be on-path, in which case it is irrelevant whether the client is able to resolve the right IP address or (2) the DNSSEC signing key is itself uncompromised [usually we just assume that keys are secure, but given that the scenario you are positing for WebPKI failure is key compromise, DNSSEC signing key compromise needs also to be in scope]. It is not necessary because, as has been noted already, we generally assume that the WebPKI provides a reasonable level of security on its own, although, as Adam observes, nothing is perfect.
> 
> -Ekr
> 
>>

---

From: Rob Sayre <[email-masked]>
Date: Sat, 8 Feb 2020 00:26:09 -0800

Hi,

Maybe DNSSEC should not appear in a consensus document until it is shown to
work. Here are some opinions about it that are negative:

https://twitter.com/colmmacc/status/979234954440617990

https://www.iab.org/documents/correspondence-reports-documents/2019-2/avoiding-unintended-harm-to-internet-infrastructure/

thanks,
Rob