Subject: Re: [Add] Fwd: New Version Notification for draft-reddy-add-server-policy-selection-06.txt

From: Ben Schwartz <[email-masked]>
Date: Mon, 1 Mar 2021 10:49:06 -0500

On Fri, Feb 26, 2021 at 3:13 AM tirumal reddy <[email-masked]> wrote:

> Hi Ben,
>
> Thanks for the review. Please see inline
>
> On Thu, 25 Feb 2021 at 21:29, Ben Schwartz <[email-masked]> wrote:
>
>>
>>
>> On Wed, Feb 24, 2021 at 12:55 AM tirumal reddy <[email-masked]> wrote:
>>
>>> The revised draft
>>> https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-06
>>> addresses comments from the WG and aligns with the requirements of
>>> “Resolver behavior self-description” presented at ADD interim.
>>>
>>
>> The draft's abstract and introduction have been adjusted to align better
>> with the purpose stated in that presentation, but In my view the content
>> does not align well.
>>
>
>> As the title suggests, this draft is concerned principally with policy,
>> whereas that presentation focused on the resolver's identity and observable
>> behaviors.
>>
>
> The draft does not discuss any policy, it's scope is restricted to
> publishing resolver information. Please clarify what policy information you
> are referring to that needs to be removed.
>

The information being published is information about the resolver's
policies.  The name of the attribute is "policyinfo".

The presentation proposes to avoid discussing policy by simply documenting
the observable behavior (e.g. a list of EDE codes that the resolver might
return).  Note that there are currently no EDE codes for "malware" or
"phishing".  You could propose the addition of such codes to the EDE
registry, separately from this draft.  (Personally, I would not be in favor
of adding them.)

Here's the relevant text from that presentation:
>>
>> ## Defining resolver identity
>> * Express information consumable by humans describing the resolver's
>> identity
>> * Ex 1: Provide human-legible documentation
>>     * Most likely a web page link to explain server identity, terms of
>> use, etc.
>>
>
> The above information is provided using
>
>  resinfourl:  A URL that points to the generic unstructured resolver
>       information (e.g., DoH APIs supported, possible HTTP status codes
>       returned by the DoH server, how to report a problem, etc.) for
>       troubleshooting purpose.  This is an optional attribute.
>

That seems fine to me.

> * Not used for decision making by any protocol peer; communicated to
>> clients for display to users
>>
>
> "resinfourl" is not used for any decision making by the end-user.
>

Yes, but much of this draft is clearly intended to guide a resolver
selection process on the client side, and as such it goes far beyond the
scope of the presentation.

> * Ex 2: Provide human-friendly description of the resolver identity
>>     * Friendly name and/or iconography for display in client UI
>> identifying configured resolver
>>
>
> The challenge with above information is it could be displayed in a
> language not understood by the user. It is not possible to support the
> above requirement without knowing the languages the user is able to
> understand.
>

It's not clear to me that the name needs to be localized.  (Chrome does not
attempt to localize DNS server UI names [1].)  However, if localization is
required, that can be addressed by fetching the name over HTTPS with
language negotiation.  This seems fairly natural, since the presentation
also calls for a way to transfer an icon, and embedding an image file in a
DNS record seems like a bad idea.

It has occurred to me that using the standard favicon and HTML <title> from
the indicated webpage might solve both problems.  Requiring an HTML parser
to extract the localized title seems unfortunate, but may be acceptable if
the description already includes a "non-localized" name.

[1]
https://source.chromium.org/chromium/chromium/src/+/master:net/dns/public/doh_provider_entry.cc

## Defining protocol support
>> * Express what optional DNS-related functionality is supported
>> * Ex 1: DNS Extended Errors and which codes to expect
>>       * Not exhaustive: server can still return any code
>>       * Codes 15-17 indicate kinds of filtering the resolver implements
>>
>
> All the above information is conveyed using "extendeddnserror",
> "policyblocking", "censoredblocking" and "filteredblocking" attributes
> (Codes 15 to 17).
>

Yes, but I don't think they should be represented as separate attributes.
Compared to simply enumerating the relevant EDE codes, this approach has
two key problems:
(1) Whenever the EDE registry is updated, this registry and any
implementing software must be updated as well to maintain parallelism.
This increases the maintenance burden on the IETF and implementers.
(2) Only a subset of EDE codes have specified equivalents.  This reduces
the level of functionality.

* Ex 2: Access-controlled resolvers describing their properties outside of
>> access control
>>
>
> It is saying whether the server needs client authentication, it is handled
> by the "clientauth" attribute.
>

There has been some discussion of whether client authentication is in-scope
for this working group, but leaving that aside, I don't think that's what
this bullet point meant.  Rather, it meant that there ought to be some way,
at least optionally, for resolvers to publish this information to
unauthenticated users even if the resolver itself is access-controlled.

I'm not sure how well the "clientauth" attribute will work as specified,
but I don't object to it.

...

> I would start by separating the Policy Assertion Token and signature
>> system into its own draft.  That signature scheme is interesting but is not
>> required to meet these goals.
>>
>
> The signature is added to ensure the client does not connect to an
> encrypted DNS server hosted by an attacker.
>

To prevent connecting to a server hosted by an attacker, we need two
things: (1) authenticated encryption of the DNS transport, and (2) resolver
identities provided securely by a trusted party.  Signed tokens are one way
to enable point 2, but there are also many other ways.  In practice, the
trusted party (e.g. Mozilla, for Firefox users) simply provides the
resolver identities to the client over an authenticated channel.  Thus,
there is no need for signatures on the resolver description itself.

Since the signatures are not needed to accomplish the goal in existing
architectures, and are a source of considerable complexity, I would prefer
to see them moved into a separate draft.

The resolver information can be conveyed either inside the PAT or
> separately (please see step 6 in
> https://tools.ietf.org/html/draft-reddy-add-server-policy-selection-06#section-9
> ).
>

This is a good design, and supports moving the PAT concept into a separate
draft.

I would also avoid any metadata keys beyond those mentioned in the
>> presentation, so we can focus on constructing a suitable extensible format
>> for metadata delivery.  More keys can be added as extensions in subsequent
>> drafts.
>>
>
> Sure but PAT is a mandatory resolver information especially in scenarios
> where Encrypted DNS server is discovered insecurely.
>

I don't think this is true.  For example, DDR (formerly DEER) enables safe
use of encrypted DNS via insecure discovery without relying on anything
like a PAT.

For delivery, I think the best option might be a TXT record in DNS-SD style
>> on _dns.$RESOLVER_NAME and _dns.resolver.arpa.  That should make manual
>> debugging easy and familiar for DNS administrators.
>>
>
> The previous version of the draft was relying on RESINFO (RESINFO draft is
> adopted in DNSOP but expired and not making any progress). The current
> version of the draft is updated to use SVCB RRtype to align with DDR.
>

I don't think this is a good use of SVCB.  SVCB RRs convey "connection
hints" for alternative endpoints that all offer the same logical service.
The information presented here is not a connection parameter, and it is not
a description of an alternative endpoint.  Rather, it is a description of
the logical service itself.  Also, repeating this information in every SVCB
RR would be inefficient.

Most importantly, https://tools.ietf.org/htm thatl/rfc5507
> <https://tools.ietf.org/html/rfc5507> discusses why using a new RR Type
> is a preferred solution rather than relying on TXT resource record.
>

RFC 6763 defined extensive use of TXT records anyway, so I don't think RFC
5507 is a strict rule.  I'm certainly open to defining a new RR type.
Perhaps we should revive RESINFO for providing general information about
the resolver as a logical service, vs. SVCB for bootstrapping the transport.

---

From: tirumal reddy <[email-masked]>
Date: Thu, 4 Mar 2021 17:41:56 +0530

Hi Ben,

Please see inline

> policies.  The name of the attribute is "policyinfo".

Thanks, fixed.

> registry, separately from this draft.  (Personally, I would not be in favor

Several public resolvers like Quad9 offer both malware filtering and
no-filtering service (see
https://www.quad9.net/news/blog/doh-with-quad9-dns-servers/).  The client
may want to know why the DNS responses are filtered.

> It's not clear to me that the name needs to be localized.  (Chrome does
> not attempt to localize DNS server UI names [1].)  However, if localization
> is required, that can be addressed by fetching the name over HTTPS with
> language negotiation.
>

Yes, added a new attribute to convey an URL that points to a human-friendly
description of the resolver identity to display to the end-user.

> This seems fairly natural, since the presentation also calls for a way to
> transfer an icon, and embedding an image file in a DNS record seems like a
> bad idea.
>
> It has occurred to me that using the standard favicon and HTML <title>
> from the indicated webpage might solve both problems.  Requiring an HTML
> parser to extract the localized title seems unfortunate, but may be
> acceptable if the description already includes a "non-localized" name.
>
> [1]

Good point, updated extendeddnserror attribute to say it will include the
possible extended DNS error codes that can be returned by the DNS server
and removed the other attributes.

>> It is saying whether the server needs client authentication, it is
>> handled by the "clientauth" attribute.
>>
>
> There has been some discussion of whether client authentication is
> in-scope for this working group, but leaving that aside, I don't think
> that's what this bullet point meant.  Rather, it meant that there ought to
> be some way, at least optionally, for resolvers to publish this information
> to unauthenticated users even if the resolver itself is access-controlled.
>

Okay.

> there is no need for signatures on the resolver description itself.

Yes but the TRR approach cannot scale. It is near impossible for every
network to approach all browsers and OS to get pre-configured. The
encrypted DNS server has no clue whether it is pre-configured in the client
or not.

> This is a good design, and supports moving the PAT concept into a separate

Thanks.

> use of encrypted DNS via insecure discovery without relying on anything

I am referring to a scenario where SUDN is used to discover
network-provided resolvers and an on-path attacker modifies the response to
convey the attacker-provided encrypted DNS server instead.

>
> For delivery, I think the best option might be a TXT record in DNS-SD
>>> style on _dns.$RESOLVER_NAME and _dns.resolver.arpa.  That should make
>>> manual debugging easy and familiar for DNS administrators.
>>>
>>
>> The previous version of the draft was relying on RESINFO (RESINFO draft
>> is adopted in DNSOP but expired and not making any progress). The current

Got it, Thanks.

> the resolver as a logical service, vs. SVCB for bootstrapping the transport.

Yes, works for me.  @Paul/Puneet - Any plans to revive RESINFO ?

Cheers,
-Tiru

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 4 Mar 2021 11:29:43 -0500

> may want to know why the DNS responses are filtered.

If you'd like to discuss extending the EDE response set, that should happen
in DNSOP.

Regarding this draft: Quad9 conveys this information on their website, and
this draft provides users with a link to it.  I think that's sufficient,
and a much better fit to the problem space, given the endless variety of
reasons someone might want to filter a DNS response.

...

> Yes, added a new attribute to convey an URL that points to a
> human-friendly description of the resolver identity to display to the
> end-user.
>

Thanks!

> and removed the other attributes.

Great!

...

> encrypted DNS server has no clue whether it is pre-configured in the client

I'm not sure what you mean by "the TRR approach".  For example, Chrome,
Windows, and Firefox all maintain lists of resolvers, each with different
behaviors and inclusion criteria.

...

> convey the attacker-provided encrypted DNS server instead.

SUDN discovery is entirely unauthenticated.  An attacker can simply spoof
the SUDN query replies, indicating that the network has no encrypted
resolver.  If the client falls back to unencrypted DNS, this attack
bypasses PAT entirely.

It sounds like you're considering a client that uses a built-in encrypted
resolver unless the network provides one that has been approved as a
replacement.  This is an interesting architecture, but I have not heard any
clients express interest in implementing it.  Additionally, I think the PAT
design is overcomplicated for this use case.  For example, the client could
simply ask its authority whether this resolver is approved.

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 4 Mar 2021 17:32:10 +0000

> I'm not sure what you mean by "the TRR approach".  For example, Chrome, Windows, and Firefox all maintain lists of resolvers, each with different behaviors and inclusion criteria.

Clarification: the Windows list is distinctly different from a TRR as it conveys no trust (or lack thereof) in any way. We do not use it to select resolvers on the user's behalf. Instead, we rely on it _in the absence of a DoH discovery protocol_ to understand if a user-selected (or network discovered) IP address does support DoH. This list should become obsolete once we can learn this information directly from the network or resolver. Fortunately, this WG has adopted a draft for each scenario.

Thanks,
Tommy

From: Add <[email-masked]> On Behalf Of Ben Schwartz
Sent: Thursday, March 4, 2021 8:30 AM
To: tirumal reddy <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: [EXTERNAL] Re: [Add] Fwd: New Version Notification for draft-reddy-add-server-policy-selection-06.txt

On Thu, Mar 4, 2021 at 7:12 AM tirumal reddy <[email-masked]<mailto:[email-masked]>> wrote:
Several public resolvers like Quad9 offer both malware filtering and no-filtering service (see https://www.quad9.net/news/blog/doh-with-quad9-dns-servers/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.quad9.net%2Fnews%2Fblog%2Fdoh-with-quad9-dns-servers%2F&data=04%7C01%7CJensen.Thomas%40microsoft.com%7Cb90e9729cd2949cc0a0e08d8df2ac644%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504722124735537%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uLD28twwiNiSfIy%2Fr51V%2BmV1FDOBIjapBg3VcPS67AY%3D&reserved=0>).  The client may want to know why the DNS responses are filtered.

If you'd like to discuss extending the EDE response set, that should happen in DNSOP.

Regarding this draft: Quad9 conveys this information on their website, and this draft provides users with a link to it.  I think that's sufficient, and a much better fit to the problem space, given the endless variety of reasons someone might want to filter a DNS response.

...
Yes, added a new attribute to convey an URL that points to a human-friendly description of the resolver identity to display to the end-user.

Thanks!

Good point, updated extendeddnserror attribute to say it will include the possible extended DNS error codes that can be returned by the DNS server and removed the other attributes.

Great!

...
To prevent connecting to a server hosted by an attacker, we need two things: (1) authenticated encryption of the DNS transport, and (2) resolver identities provided securely by a trusted party.  Signed tokens are one way to enable point 2, but there are also many other ways.  In practice, the trusted party (e.g. Mozilla, for Firefox users) simply provides the resolver identities to the client over an authenticated channel.  Thus, there is no need for signatures on the resolver description itself.

Yes but the TRR approach cannot scale. It is near impossible for every network to approach all browsers and OS to get pre-configured. The encrypted DNS server has no clue whether it is pre-configured in the client or not.

I'm not sure what you mean by "the TRR approach".  For example, Chrome, Windows, and Firefox all maintain lists of resolvers, each with different behaviors and inclusion criteria.

...
I am referring to a scenario where SUDN is used to discover network-provided resolvers and an on-path attacker modifies the response to convey the attacker-provided encrypted DNS server instead.

SUDN discovery is entirely unauthenticated.  An attacker can simply spoof the SUDN query replies, indicating that the network has no encrypted resolver.  If the client falls back to unencrypted DNS, this attack bypasses PAT entirely.

It sounds like you're considering a client that uses a built-in encrypted resolver unless the network provides one that has been approved as a replacement.  This is an interesting architecture, but I have not heard any clients express interest in implementing it.  Additionally, I think the PAT design is overcomplicated for this use case.  For example, the client could simply ask its authority whether this resolver is approved.

---

From: tirumal reddy <[email-masked]>
Date: Sat, 6 Mar 2021 12:44:02 +0530

Hi Ben,

Please see inline

On Thu, 4 Mar 2021 at 21:59, Ben Schwartz <[email-masked]> wrote:

>> https://www.quad9.net/news/blog/doh-with-quad9-dns-servers/).  The
>> client may want to know why the DNS responses are filtered.
>>
>

Good point.  Updated draft to request IANA to assign a new extended DNS
Error Code for "Threat Blocking". The error code is generic to block
security threats including malware, phishing and ransomware.  It is an
overkill to publish a new draft for a single new extended DNS error code :)

I also removed the attribute "filtering" and sub-attributes
("malwarefiltering", "phishingblocking", "policyblocking" and
"censoredblocking").  The error codes returned by the DNS server in
"extendeddnserror" attribute will suffice to identify the DNS server
performs filtering and provides the reasons for filtering.

> behaviors and inclusion criteria.

I meant the approaches used today by browsers to get added as a TRR (e.g.,
see https://wiki.mozilla.org/Security/DOH-resolver-policy and
https://docs.google.com/document/d/128i2YTV2C7T6Gr3I-81zlQ-_Lprnsp24qzy_20Z1Psw/edit
).

> resolver.  If the client falls back to unencrypted DNS, this attack

Agreed, DHCP/RA is also unauthenticated (but less prone to spoofing attack
because of DHCP-shield and RA guard).  In case of SUDN (opportunistic or
authenticated discovery), PAT identifies connection to an encrypted
resolver hosted by an attacker.

> clients express interest in implementing it.
>

It is the start of a discussion to avoid potential threats.

> Additionally, I think the PAT design is overcomplicated for this use
> case.  For example, the client could simply ask its authority whether this
> resolver is approved.
>

What authority are you referring to (TRR or something else) ?

Cheers,
-Tiru

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 8 Mar 2021 08:00:59 -0500

On Sat, Mar 6, 2021 at 2:14 AM tirumal reddy <[email-masked]> wrote:
...

> Updated draft to request IANA to assign a new extended DNS Error Code for
> "Threat Blocking". The error code is generic to block security threats
> including malware, phishing and ransomware.  It is an overkill to publish a
> new draft for a single new extended DNS error code :)
>

I would prefer to do this separately.  Extending the DNS Error Codes seems
likely to be more appropriate for DNSOP than ADD.  Also, this error code
seems extremely similar to Code 15 ("Blocked"), and I prefer that
definition.
...

> It is the start of a discussion to avoid potential threats.

That's a fine discussion to have, but we should not block development of a
simple resolver description format while we consider hypothetical use cases.

> What authority are you referring to (TRR or something else) ?

PAT, like any TRR model, assumes an authority respected by the client who
determines which resolvers are trustworthy.  Defining a new object
signature architecture is one way to achieve this, but far from the only
way.  A simpler approach that might suffice is to simply ask the authority.

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 8 Mar 2021 14:48:56 +0100 (CET)

>     Il 08/03/2021 14:00 Ben Schwartz <bemasc=[email-masked]> ha scritto:
> 
> 
> 
> 
>     On Sat, Mar 6, 2021 at 2:14 AM tirumal reddy <[email-masked] mailto:[email-masked] > wrote:
>     ...
> 
>         > >         Updated draft to request IANA to assign a new extended DNS Error Code for "Threat Blocking". The error code is generic to block security threats including malware, phishing and ransomware.  It is an overkill to publish a new draft for a single new extended DNS error code :)
> > 
> >     > 
>     I would prefer to do this separately.  Extending the DNS Error Codes seems likely to be more appropriate for DNSOP than ADD.  Also, this error code seems extremely similar to Code 15 ("Blocked"), and I prefer that definition.
> 
The way we defined the blocking codes in RFC 8914 was to distinguish them by who took the decision to block the domain:
#15 (Blocked) = the resolver operator decided to block
#17 (Filtered) = the user decided to block (by asking the operator to activate filters for a certain type of domains)
#16 (Censored) = someone who is neither the operator nor the user decided to block (possibly a public authority of some kind)

The codes are not related to which type of domains are being blocked or why. That would be a second, orthogonal classification; malware domains could be blocked unilaterally by the operator, or because of a user request, or because of a court order; operators could be blocking malware, but also CSAM, and so on.

So I think that any information on content type / reason for blocking should rather go into the extra-text field, perhaps structuring it a little. Alternatively, one could imagine adding a different set of "by category" EDE blocking codes and then sending two EDE codes at a time, one to specify the source of the block and another one to specify the category of blocked content, but I don't know if that's feasible under current specifications or if it would ever work.

Also, while it is relatively easy to distinguish the source of a block, it may not be that easy to identify content categories objectively. So this would be a relatively unreliable indication, as different operators could assign the same domain to different categories.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: tirumal reddy <[email-masked]>
Date: Tue, 9 Mar 2021 13:30:06 +0530

> seems extremely similar to Code 15 ("Blocked"), and I prefer that

I see your point, removed "Threat Blocking".

>> Agreed, DHCP/RA is also unauthenticated (but less prone to spoofing
>> attack because of DHCP-shield and RA guard).  In case of
>> SUDN (opportunistic or authenticated discovery), PAT identifies connection
>> to an encrypted resolver hosted by an attacker.
>>
>>
>>> It sounds like you're considering a client that uses a built-in
>>> encrypted resolver unless the network provides one that has been approved
>>> as a replacement.  This is an interesting architecture, but I have not
>>> heard any clients express interest in implementing it.
>>>
>>

I plan to bring it up during the presentation of this draft this week to
discuss if the cryptographic assertion needs to be discussed separately.

> way.  A simpler approach that might suffice is to simply ask the authority.

Out of band communication has its shortcomings, the WG needs to discuss and
pick a suitable technique to avoid the threats discussed above.

-Tiru