Subject: [Add] WGLC for draft-ietf-add-svcb-dns

From: "Deen, Glenn" <[email-masked]>
Date: Thu, 24 Feb 2022 16:00:19 +0000

Finally, the 3rd document being placed in ADD WGLC today:

The ADD draft Service Binding Mapping for DNS Servers https://datatracker.ietf.org/doc/draft-ietf-add-svcb-dns/  is ready for WGLC.

WGLC will run until March 14th, please post all comments to the ADD mailing list.

ADD Co-chairs
Glenn Deen & David Lawrence

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 24 Feb 2022 11:08:33 -0500

With apologies to the chairs...

After confirming that this draft was ready for WGLC, I learned of an
additional consideration for this draft related to port number collisions.
I've written up some proposed text [1] discussing this issue and making
recommendations on how to handle it, but I wanted to get some more input
before publishing a revised draft.

The additional text is as follows:

Support for the `port` key can be unsafe if the client has implicit
> elevated access to some network service (e.g. a local service that is
> inaccessible to remote parties) and that service uses a TCP-based protocol
> other than TLS.  A hostile DNS server might be able to manipulate this
> service by causing the client to send a specially crafted TLS SNI or
> session ticket that can be misparsed as a command or exploit.  To avoid
> such attacks, clients SHOULD NOT support the `port` key unless one of the
> following conditions applies:
>
> * The client is being used with a DNS server that is highly trusted.
> * The client is being used in a context where implicit elevated access
> cannot apply.
> * The client restricts the set of allowed TCP port values to exclude any
> ports where a confusion attack is likely to be possible (e.g. the "bad
> ports" list from {{FETCH}}).
>

I would appreciate group's input on this text.

Thanks,
Ben

[1] https://github.com/ietf-wg-add/draft-ietf-add-svcb-dns/pull/11

On Thu, Feb 24, 2022 at 11:01 AM Deen, Glenn <Glenn_Deen=
[email-masked]> wrote:

> The ADD draft Service Binding Mapping for DNS Servers
> https://datatracker.ietf.org/doc/draft-ietf-add-svcb-dns/  is ready for
> WGLC.
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: "Deen, Glenn" <[email-masked]>
Date: Thu, 24 Feb 2022 16:23:40 +0000

HI Ben,

Given that this is an additional set of text directed at adopters and it does not change the document otherwise, I suggest we continue with the WGLC and handle discussion of this additional text like a WGLC comment submitted by yourself (Ben).

-glenn

On 2/24/22, 8:09 AM, "Add on behalf of Ben Schwartz" <[email-masked]<mailto:[email-masked]> on behalf of bemasc=[email-masked]<mailto:[email-masked]>> wrote:

After confirming that this draft was ready for WGLC, I learned of an additional consideration for this draft related to port number collisions.  I've written up some proposed text [1] discussing this issue and making recommendations on how to handle it, but I wanted to get some more input before publishing a revised draft.

Support for the `port` key can be unsafe if the client has implicit elevated access to some network service (e.g. a local service that is inaccessible to remote parties) and that service uses a TCP-based protocol other than TLS.  A hostile DNS server might be able to manipulate this service by causing the client to send a specially crafted TLS SNI or session ticket that can be misparsed as a command or exploit.  To avoid such attacks, clients SHOULD NOT support the `port` key unless one of the following conditions applies:

* The client is being used with a DNS server that is highly trusted.
* The client is being used in a context where implicit elevated access cannot apply.
* The client restricts the set of allowed TCP port values to exclude any ports where a confusion attack is likely to be possible (e.g. the "bad ports" list from {{FETCH}}).

Thanks,
Ben

On Thu, Feb 24, 2022 at 11:01 AM Deen, Glenn <Glenn_Deen=[email-masked]<mailto:[email-masked]>> wrote:
Finally, the 3rd document being placed in ADD WGLC today:

ADD Co-chairs

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add

---

From: Puneet Sood <[email-masked]>
Date: Thu, 24 Feb 2022 18:26:02 -0500

For the record, reposting a slightly edited version of an earlier
comment to the last call thread. This is related to
https://github.com/ietf-wg-add/draft-ietf-add-ddr/issues/58 and
https://datatracker.ietf.org/doc/html/rfc6303#section-3.

Section 4.1 Discovery Using Resolver IP Addresses has this sentence:

"If the recursive resolver that receives this query has no Designated
Resolvers, it SHOULD return NODATA for queries to the "resolver.arpa"
SUDN."

This needs to be expanded so that a resolver that supports DDR treats
the resolver.arpa zone as a locally served zone (RFC 6303).

- resolver.arpa/*: NODATA
- _dns.resolver.arpa/{ANY|SVCB}: SVCB record
- _dns.resolver.arpa/<other types>: NODATA

The resolver is taking ownership of resolver.arpa, so to be fully
compliant it should be answering for everything under resolver.arpa?
- *.resolver.arpa/*: NXDOMAIN

I do not think the NODATA, NXDOMAIN responses need to return any
SOA/NS records in the AUTHORITY section.
https://datatracker.ietf.org/doc/html/rfc2308#section-2.2 example 3
gives leeway to an implementation to omit the authority section. Given
the DDR responses will primarily be processed by stub resolvers which
are not performing iterative resolution, the lack of SOA/NS is not a
problem.

-Puneet