Subject: [Add] DHCP/SVCB Sync (RE: Incompatibility attack)

From: <[email-masked]>
Date: Tue, 9 Mar 2021 17:08:54 +0000

Re-,

Focuing on this one.

Cheers,
Med

DDR Section 5 considers the case of a resolver that is known to the client only by its name.  The client doesn't know "a priori" which protocols the server supports.  For example, if users type the resolver's name into a UI element, the UI might not ask the user to indicate which protocols that resolver supports.

For DNR, I agree that it would be possible to "commit" to certain protocols on the client side, so the client can fail hard if they are not available.  However, this approach seems operationally challenging to me, because it requires synchronizing the DHCP and SVCB contents.

[Med] Synchronization is not an issue. The DHCP server can issue the SVCB, cache them, and use them to populate the options sent to requesting clients. See for example rfc7969 (search for “resolves the domain names »).

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 9 Mar 2021 12:55:59 -0500

On Tue, Mar 9, 2021 at 12:08 PM <[email-masked]> wrote:

> Re-,
>
>
>
> Focuing on this one.
>
>
>
> Cheers,
>
> Med
>
>
>
>
>
> DDR Section 5 considers the case of a resolver that is known to the client
> only by its name.  The client doesn't know "a priori" which protocols the
> server supports.  For example, if users type the resolver's name into a UI
> element, the UI might not ask the user to indicate which protocols that
> resolver supports.
>
>
>
> For DNR, I agree that it would be possible to "commit" to certain
> protocols on the client side, so the client can fail hard if they are not
> available.  However, this approach seems operationally challenging to me,
> because it requires synchronizing the DHCP and SVCB contents.
>
>
>

This creates a circular dependency: the DHCP server fetches this
information over DNS, which is (hopefully) secured by DDR, which has this
vulnerability.  To solve this, the DNS server would have to commit to not
falling back to Do53, i.e. shutting down all users' DNS.  The effect of
this is similar to MTI: servers must implement enough protocols to be
compatible with every DHCP server implementation.  The practical effect is
likely to be strictly more constraining on servers, which will almost
certainly have to implement DoT, and potentially will also have to
implement other protocols, to avoid entire networks going dark.

---

From: <[email-masked]>
Date: Tue, 9 Mar 2021 18:06:55 +0000

Re-,

Please see inline.

Cheers,
Med

De : Ben Schwartz [mailto:[email-masked]]
Envoyé : mardi 9 mars 2021 18:56
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
Cc : ADD Mailing list <[email-masked]>
Objet : Re: DHCP/SVCB Sync (RE: [Add] Incompatibility attack)

On Tue, Mar 9, 2021 at 12:08 PM <[email-masked]<mailto:[email-masked]>> wrote:
Re-,

Focuing on this one.

Cheers,
Med

This creates a circular dependency: the DHCP server fetches this information over DNS, which is (hopefully) secured by DDR, which has this vulnerability.  To solve this, the DNS server would have to commit to not falling back to Do53, i.e. shutting down all users' DNS.  The effect of this is similar to MTI: servers must implement enough protocols to be compatible with every DHCP server implementation.  The practical effect is likely to be strictly more constraining on servers, which will almost certainly have to implement DoT, and potentially will also have to implement other protocols, to avoid entire networks going dark.

[Med] You may notice that I said “can”. The issue of the circular dependency will be there independently whether SVCB resolution is triggered by the client or the server. That’s an issue I personally have with trying to tightly coupling DDR and DNR.

I do see a value in relaxing the constraint on DNR side to supply the required information without SVCB. Of course, we should allow to make use of it, but it should not be mandatory.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 9 Mar 2021 18:17:52 +0000

On Tue, Mar 09, 2021 at 12:55:59PM -0500, Ben Schwartz wrote:
> > ...
> > [Med] Synchronization is not an issue. The DHCP server can issue the
> > SVCB, cache them, and use them to populate the options sent to
> > requesting clients. See for example rfc7969 (search for ???resolves
> > the domain names ??).
> 
> vulnerability.

i expected these queries to be secured by DNSSEC (data authenticity) rather
than any form of transport security (counterparty identity and/or privacy).

> To solve this, the DNS server would have to commit to not
> falling back to Do53, i.e. shutting down all users' DNS.

i think this will be a requirement for any transport-security-dependent
work flow, not just dhcp servers fetching svcb records. this ought to give
us pause when designing transport-security-dependent workflows.

> ...

-- 
Paul Vixie

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 9 Mar 2021 16:13:14 -0500

On Tue, Mar 9, 2021 at 1:06 PM <[email-masked]> wrote:

> Re-,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Ben Schwartz [mailto:[email-masked]]
> *Envoyé :* mardi 9 mars 2021 18:56
> *À :* BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> *Cc :* ADD Mailing list <[email-masked]>
> *Objet :* Re: DHCP/SVCB Sync (RE: [Add] Incompatibility attack)
>
>
>
>
>
>
>
> [Med] You may notice that I said “can”. The issue of the circular
> dependency will be there independently whether SVCB resolution is triggered
> by the client or the server.
>

Requiring clients and servers to support DoT (on any port) is sufficient to
break the cycle and enable secure upgrade, even if DoT is never used.

> That’s an issue I personally have with trying to tightly coupling DDR and
> DNR.
>

How am I supposed to configure my home router to do DNR?  I think the
answer should not be more complicated than "type in the DNS server name".

I do see a value in relaxing the constraint on DNR side to supply the
> required information without SVCB. Of course, we should allow to make use
> of it, but it should not be mandatory.
>

OK.  To enable that, I think we should structure the DNR option as follows:
* Mandatory: Authentication Domain Name
* Optional: One or more DNS records in RFC 1035 format [1]

Clients perform DDR Section 5 connection to the Authentication Domain
Name.  Before each DNS query required for that process, they check if any
corresponding records are already in the DNR option.  If so, they skip that
query and use the records from DNR.

If the network is offering multiple encrypted DNS servers, they each go in
a separate Option.

[1] https://tools.ietf.org/html/rfc1035#section-3.2.1

---

From: <[email-masked]>
Date: Wed, 10 Mar 2021 06:11:38 +0000

Hi Ben,

Please see inline.

Cheers,
Med

Envoyé : mardi 9 mars 2021 22:13

 This creates a circular dependency: the DHCP server fetches this information over DNS, which is (hopefully) secured by DDR, which has this vulnerability.  To solve this, the DNS server would have to commit to not falling back to Do53, i.e. shutting down all users' DNS.  The effect of this is similar to MTI: servers must implement enough protocols to be compatible with every DHCP server implementation.  The practical effect is likely to be strictly more constraining on servers, which will almost certainly have to implement DoT, and potentially will also have to implement other protocols, to avoid entire networks going dark.
[Med] You may notice that I said “can”. The issue of the circular dependency will be there independently whether SVCB resolution is triggered by the client or the server.
Requiring clients and servers to support DoT (on any port) is sufficient to break the cycle and enable secure upgrade, even if DoT is never used.
[Med] Still not sure to get your point here as I don’t want to downgrade by design the security protection of DNR to be the one of the DDR. If the DoT-capable client is not aware of the port number that is used to reach the DoT server, SVCB queries will be sent over Do53 (and hence the issue raised by Tiru). Let alone that the encrypted server and Do53 may not be available on the same IP@.

Unlike DDR where we manipulate “hints”, the DNR is ** more deterministic ** and should provide the information that is designated by the network. Supplying the information where to locate an encrypted server allows a client to directly establish a secure connection with the designated server and then retrieve what additional information is needed for a given encrypted DNS scheme (URI templates, for example).

That’s an issue I personally have with trying to tightly coupling DDR and DNR.

How am I supposed to configure my home router to do DNR?  I think the answer should not be more complicated than "type in the DNS server name".
[Med] You can configure a name and a locator if you don’t want to dependent on another resolver to resolve the name.

OK.
[Med] Great.

  To enable that, I think we should structure the DNR option as follows:
* Mandatory: Authentication Domain Name
[Med] Let’s park this one for the moment.

* Optional: One or more DNS records in RFC 1035 format [1]
[Med] I have many concerns with this approach:

·         This assumes that the DHCP server ** will always ** rely on a DNS source information to supply the configuration. This is not a valid assumption. Encrypted servers can be discovered without requiring SVCB record configuration. I’m thinking about DoT and DoT where providing an authentication domain name and a list of IP addresses would be sufficient to establish a secure connection.

·         If we echo that format, this would mean that the DHCP option for example will have a complex internal structure. A recommendation for DHCPv6 options design is to simplify their format and split them into separate simple options.

·         This will complicate the validation at the DHCP client side.

Clients perform DDR Section 5 connection to the Authentication Domain Name.
[Med] This is covered in the draft, but only for the DoH case (Section 7). Why a DoT client that asked only for a DoT service will issue the queries if it received from the network the ADN and where to reach the designated server?

  Before each DNS query required for that process, they check if any corresponding records are already in the DNR option.  If so, they skip that query and use the records from DNR.

If the network is offering multiple encrypted DNS servers, they each go in a separate Option.
[Med] That’s already the case in the draft.

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 10 Mar 2021 09:57:33 -0500

On Wed, Mar 10, 2021 at 1:11 AM <[email-masked]> wrote:

> *Envoyé :* mardi 9 mars 2021 22:13
> Requiring clients and servers to support DoT (on any port) is sufficient
> to break the cycle and enable secure upgrade, even if DoT is never used.
>
> [Med] Still not sure to get your point here as I don’t want to downgrade
> by design the security protection of DNR to be the one of the DDR.
>

I'm speaking about DDR Section 5 ("Discovery Using Resolver Names"),
which is fully secured (except for the MTI issue I raised here).  I don't
think there's any way that DNR could be more secure than this.

> If the DoT-capable client is not aware of the port number that is used to
> reach the DoT server, SVCB queries will be sent over Do53 (and hence the
> issue raised by Tiru).
>

Yes, but this does not affect the security guarantee.  An adversary who
interferes with this lookup cannot gain access to the client's query
stream, because (in DDR Section 5 and DNR) the client requires the
Encrypted DNS server to authenticate to the original provisioned name.

> Let alone that the encrypted server and Do53 may not be available on the
> same IP@.
>
>
>
> Unlike DDR where we manipulate “hints”, the DNR is ** more deterministic
> ** and should provide the information that is designated by the network.
> Supplying the information where to locate an encrypted server allows a
> client to directly establish a secure connection with the designated server
> and then retrieve what additional information is needed for a given
> encrypted DNS scheme (URI templates, for example).
>

I don't understand.  How can I establish a secure connection to a DoH
server before I have the DoH templates?  Are you saying that DoT support is
mandatory in DNR?

> [Med] You can configure a name and a locator if you don’t want to
> dependent on another resolver to resolve the name.
>

My claim here is that we need an MTI protocol for DDR to be secure.  For
router configuration, my concern is that typing in a domain name (and even
an IP address and port) is not sufficient if the set of supported protocols
is discovered insecurely.  I would rather not require users to type in a
domain name _and_ specify the server's supported protocols to achieve
security.  That would also limit operational flexibility: users would be
pinning aspects of server configuration that a server operator might wish
to change.

> ·         This assumes that the DHCP server ** will always ** rely on a
> DNS source information to supply the configuration. This is not a valid
> assumption.
>
No, it doesn't assume that.  These fields could be produced by the DHCP
server locally, without ever consulting the global DNS, if it has total
confidence in the server's permanent configuration.  When the DHCP server
_is_ the DNS server (local Encrypted DNS), this allows a single codebase to
implement DDR and DNR.

> Encrypted servers can be discovered without requiring SVCB record
> configuration. I’m thinking about DoT and DoT where providing an
> authentication domain name and a list of IP addresses would be sufficient
> to establish a secure connection.
>
For DoT, the resolver could synthesize an answer like:

_dns.resolver.example IN SVCB $TTL 1 resolver.example.
resolver.example. IN A $TTL 192.0.2.1
resolver.example. IN AAAA $TTL 2001:db8::1

This seems straightforward.

> ·         If we echo that format, this would mean that the DHCP option
> for example will have a complex internal structure. A recommendation for
> DHCPv6 options design is to simplify their format and split them into
> separate simple options.
>
Every client of this specification necessarily has a DNS stub resolver in
it already, so reusing the DNS record format is simpler to implement than
defining a new format.  It also avoids discrepancies between DDR and DNR,
with some configurations being representable only in one mode but not the
other.

> [Med] This is covered in the draft, but only for the DoH case (Section 7).
> Why a DoT client that asked only for a DoT service will issue the queries
> if it received from the network the ADN and where to reach the designated
> server?
>

I am not proposing that it would do so.  In the above example, the client
would not emit any DNS queries, because each step of the DDR process would
be satisfied by the information already present in the DHCP option.

---

From: <[email-masked]>
Date: Thu, 11 Mar 2021 05:50:27 +0000

Hi Ben,

Please see inline.

Cheers,
Med

Envoyé : mercredi 10 mars 2021 15:58

On Wed, Mar 10, 2021 at 1:11 AM <[email-masked]<mailto:[email-masked]>> wrote:
[..]
 De : Ben Schwartz [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : mardi 9 mars 2021 22:13
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]<mailto:[email-masked]>>
Cc : ADD Mailing list <[email-masked]<mailto:[email-masked]>>
Objet : Re: DHCP/SVCB Sync (RE: [Add] Incompatibility attack)
 DDR Section 5 considers the case of a resolver that is known to the client only by its name.  The client doesn't know "a priori" which protocols the server supports.  For example, if users type the resolver's name into a UI element, the UI might not ask the user to indicate which protocols that resolver supports.
 For DNR, I agree that it would be possible to "commit" to certain protocols on the client side, so the client can fail hard if they are not available.  However, this approach seems operationally challenging to me, because it requires synchronizing the DHCP and SVCB contents.

 This creates a circular dependency: the DHCP server fetches this information over DNS, which is (hopefully) secured by DDR, which has this vulnerability.  To solve this, the DNS server would have to commit to not falling back to Do53, i.e. shutting down all users' DNS.  The effect of this is similar to MTI: servers must implement enough protocols to be compatible with every DHCP server implementation.  The practical effect is likely to be strictly more constraining on servers, which will almost certainly have to implement DoT, and potentially will also have to implement other protocols, to avoid entire networks going dark.
[Med] You may notice that I said “can”. The issue of the circular dependency will be there independently whether SVCB resolution is triggered by the client or the server.
Requiring clients and servers to support DoT (on any port) is sufficient to break the cycle and enable secure upgrade, even if DoT is never used.
[Med] Still not sure to get your point here as I don’t want to downgrade by design the security protection of DNR to be the one of the DDR.

I'm speaking about DDR Section 5 ("Discovery Using Resolver Names"), which is fully secured (except for the MTI issue I raised here).  I don't think there's any way that DNR could be more secure than this.

[Med] Agreed, assuming the client is provided with an alternate port number that may be required for establishing the MTI secure connection.

If the DoT-capable client is not aware of the port number that is used to reach the DoT server, SVCB queries will be sent over Do53 (and hence the issue raised by Tiru).

Yes, but this does not affect the security guarantee.  An adversary who interferes with this lookup cannot gain access to the client's query stream, because (in DDR Section 5 and DNR) the client requires the Encrypted DNS server to authenticate to the original provisioned name.

[Med] I’m OK with this part. This is already covered in the draft. The assumption is to supply the required locator infor (@/port) to establish such connection.

Let alone that the encrypted server and Do53 may not be available on the same IP@.

I don't understand.  How can I establish a secure connection to a DoH server before I have the DoH templates?  Are you saying that DoT support is mandatory in DNR?

[Med] This is a fair point. That’s me still thinking that svcb should cover part of what RESINFO was doing. We are in territory where we are discussing imposing some capabilities on the services we are discovering. I still don’t like this idea for DNR as we have the channel to supply whatever the network designated.
That’s an issue I personally have with trying to tightly coupling DDR and DNR.

How am I supposed to configure my home router to do DNR?  I think the answer should not be more complicated than "type in the DNS server name".
[Med] You can configure a name and a locator if you don’t want to dependent on another resolver to resolve the name.
My claim here is that we need an MTI protocol for DDR to be secure.  For router configuration, my concern is that typing in a domain name (and even an IP address and port) is not sufficient if the set of supported protocols is discovered insecurely.  I would rather not require users to type in a domain name _and_ specify the server's supported protocols to achieve security.  That would also limit operational flexibility: users would be pinning aspects of server configuration that a server operator might wish to change.
I do see a value in relaxing the constraint on DNR side to supply the required information without SVCB. Of course, we should allow to make use of it, but it should not be mandatory.

OK.
[Med] Great.

•         This assumes that the DHCP server ** will always ** rely on a DNS source information to supply the configuration. This is not a valid assumption.
No, it doesn't assume that.  These fields could be produced by the DHCP server locally, without ever consulting the global DNS, if it has total confidence in the server's permanent configuration.

[Med] Hmm, why DHCP servers will need to craft the data following that format then, while they can use the simple format they are used to do? I understand that it is tempting to preserve that format if the DHCP makes some queries to populates it replies.

  When the DHCP server _is_ the DNS server (local Encrypted DNS)

[Med] There might be optimization for this case, but I’d like we get us out of making deployment assumptions.

, this allows a single codebase to implement DDR and DNR.

Encrypted servers can be discovered without requiring SVCB record configuration. I’m thinking about DoT and DoT where providing an authentication domain name and a list of IP addresses would be sufficient to establish a secure connection.
For DoT, the resolver could synthesize an answer like:

[Med] It seems but it isn’t. Some preparation work is needed:

·         The ADN is already communicated

·         TTL is redundant with the lease and lifetime in DHCP/RA

·         IPv4 @es should not be included in DHCPv6 option

·         IPv6 @es should not be included in DHCPv4 options

The formatting of DHCP options should follow a set of guidelines. Let’s not add more complication to the design as we will need to progress this spec with dhc and 6man WGs.

•         If we echo that format, this would mean that the DHCP option for example will have a complex internal structure. A recommendation for DHCPv6 options design is to simplify their format and split them into separate simple options.

•         This will complicate the validation at the DHCP client side.
Every client of this specification necessarily has a DNS stub resolver

[Med] Yes, but the validation should at the dhcp client level before passing it to the DNS stub resolver. Blindly passing data is not recommended.

in it already, so reusing the DNS record format is simpler to implement than defining a new format.  It also avoids discrepancies between DDR and DNR, with some configurations being representable only in one mode but not the other.

I am not proposing that it would do so.  In the above example, the client would not emit any DNS queries, because each step of the DDR process would be satisfied by the information already present in the DHCP option.

[Med] Thanks for the clarification.

---

From: Neil Cook <[email-masked]>
Date: Thu, 11 Mar 2021 10:28:12 +0000

> On 11 Mar 2021, at 05:50, [email-masked] wrote:
> 
> De : Ben Schwartz [mailto:[email-masked] <mailto:[email-masked]>] 
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked] <mailto:[email-masked]>>
> Cc : ADD Mailing list <[email-masked] <mailto:[email-masked]>>

This is an important point, and is also essential for the use-case where DNR will be used with a local encrypted DNS resolver/forwarder on a private IP address. It also adds weight to the notion discussed in Tuesday’s session that DNR should contain either just the ADN (ok, but not an option for the use-case above) or ADN plus *everything* needed to securely connect. I think that the encoding discussion is separate from that, and we shouldn’t be tempted to conflate them.

-- 
kind regards,
Neil Cook
Head of Product, PowerDNS 
Phone: +44 774 7012545 
Email: [email-masked]
Direct Chat: https://chat.open-xchange.com/direct/neil.cook
-------------------------------------------------------------------------------------
Open-Xchange AG, Hohenzollernring 72, 50672 Cologne, District Court Cologne HRB 95366 
Managing Board: Andreas Gauger, Carsten Dirks, Dirk Valbert, Stephan Martin 
Chairman of the Board: Richard Seibt

European Office: 
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718 
Managing Director: Frank Hoberg

US Office: 
Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA 
-------------------------------------------------------------------------------------