Subject: [Add] Incompatibility attack

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

Tiru made an important point in the last minute of the ADD session today.
A DNS intermediary attacker can synthesize a SVCB response for
_dns.resolver.example indicating that the only encrypted protocol available
is HTTP/99, or some other nonexistent ALPN.  Under the current drafts, the
client would conclude that the server is incompatible and fall back to
insecure Do53.  Although we were talking about DNR, this attack applies to
DDR "Discovery Using Resolver Names" (Section 5) generally.

To solve this problem, I think we should make DNS-over-TLS "Mandatory To
Implement" for DDR.  Phrased correctly, this requirement would be
sufficient to ensure that a DNS attacker cannot force a fallback to Do53.
It would also give us a clear answer to any concerns about compatibility.

--Ben Schwartz

---

From: <[email-masked]>
Date: Tue, 9 Mar 2021 16:16:47 +0000

Re-,

From the DNR standpoint, I’m not sure whether this is sufficient as DoT may not be available on the default port number. This is one of the reasons we allows to supply the IP address and an alternate port number.

Requiring DoT to discover DoQ for example may not be justified.

Cheers,
Med

De : Add [mailto:[email-masked]] De la part de Ben Schwartz
Envoyé : mardi 9 mars 2021 16:52
À : ADD Mailing list <[email-masked]>
Objet : [Add] Incompatibility attack

Tiru made an important point in the last minute of the ADD session today.  A DNS intermediary attacker can synthesize a SVCB response for _dns.resolver.example indicating that the only encrypted protocol available is HTTP/99, or some other nonexistent ALPN.  Under the current drafts, the client would conclude that the server is incompatible and fall back to insecure Do53.  Although we were talking about DNR, this attack applies to DDR "Discovery Using Resolver Names" (Section 5) generally.

To solve this problem, I think we should make DNS-over-TLS "Mandatory To Implement" for DDR.  Phrased correctly, this requirement would be sufficient to ensure that a DNS attacker cannot force a fallback to Do53.  It would also give us a clear answer to any concerns about compatibility.

--Ben Schwartz

_________________________________________________________________________________________________________________________

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 11:33:45 -0500

On Tue, Mar 9, 2021 at 11:16 AM <[email-masked]> wrote:

> Re-,
>
>
>
> From the DNR standpoint, I’m not sure whether this is sufficient as DoT
> may not be available on the default port number. This is one of the reasons
> we allows to supply the IP address and an alternate port number.
>

I don't think that's a problem.  We would make it mandatory for clients to
support alternate port numbers.

> Requiring DoT to discover DoQ for example may not be justified.

Yes, this would require both client and server to implement DoT, even if
they actually want to use DoQ.  However, it would not require them to
actually use DoT, if DoQ is available.  I don't think this is an
unreasonable imposition.

>
>
> Cheers,
>
> Med
>
>
>
> *De :* Add [mailto:[email-masked]] *De la part de* Ben Schwartz
> *Envoyé :* mardi 9 mars 2021 16:52
> *À :* ADD Mailing list <[email-masked]>
> *Objet :* [Add] Incompatibility attack
>
>
>

---

From: <[email-masked]>
Date: Tue, 9 Mar 2021 16:44:20 +0000

Re-,

Please see inline.

Cheers,
Med

De : Ben Schwartz [mailto:[email-masked]]
Envoyé : mardi 9 mars 2021 17:34
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
Cc : ADD Mailing list <[email-masked]>
Objet : Re: [Add] Incompatibility attack

On Tue, Mar 9, 2021 at 11:16 AM <[email-masked]<mailto:[email-masked]>> wrote:
Re-,

I don't think that's a problem.  We would make it mandatory for clients to support alternate port numbers.
[Med] Not sure to get your point. The issue I have is on the server side: how to know the alternate port number?

Yes, this would require both client and server to implement DoT, even if they actually want to use DoQ.  However, it would not require them to actually use DoT, if DoQ is available.  I don't think this is an unreasonable imposition.

[Med] Why not do what we do have currently in the DNR draft: use the discovered name and IP address to establish the authenticated connection that is indicated in the option (e.g., DoQ, DoT). We don’t impose specific encrypted mode for the sole purpose of discovery.

Cheers,
Med

De : Add [mailto:[email-masked]<mailto:[email-masked]>] De la part de Ben Schwartz
Envoyé : mardi 9 mars 2021 16:52
À : ADD Mailing list <[email-masked]<mailto:[email-masked]>>
Objet : [Add] Incompatibility attack

--Ben Schwartz

Thank you.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 9 Mar 2021 11:57:32 -0500

On Tue, Mar 9, 2021 at 11:44 AM <[email-masked]> wrote:
...

> how to know the alternate port number?

The server chooses whatever port numbers it wants to operate its services.
If it chooses non-default ports, it uses a "port=..." SvcParamKey in SVCB
to indicate the port number.

> [Med] Why not do what we do have currently in the DNR draft: use the
> discovered name and IP address to establish the authenticated connection
> that is indicated in the option (e.g., DoQ, DoT).
>

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.

> We don’t impose specific encrypted mode for the sole purpose of discovery.
>

To be clear, I'm not proposing that anyone must actually use DoT, only that
it must be supported.  This ensures that all clients can actually connect
to all servers, eliminating the incompatibility-fallback case.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 Mar 2021 18:30:30 -0800

> DDR "Discovery Using Resolver Names" (Section 5) generally.

How is this different from synthesizing a response without SVCB?

-Ekr

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

---

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

The scenario is: a trusted source tells you "resolver.example supports
encryption.  Query SVCB for details.".  If you do a SVCB query and get
NODATA, you can fail hard: it's an attack.  But what if you get back SVCB
that looks correct but is not compatible with you?  You can't encrypt, and
you don't know whether there was an attack.

I think Discovery Using Resolver Names (DDR Section 5) matches this
pattern, and therefore has this problem.  We could solve it a few ways:
* Declare that this discovery mechanism is not actually secure unless you
use DNSSEC
* Demand hard failure on incompatibility if you want security
* Specify an MTI baseline

The last two are basically pretty similar.  If secure clients fail hard on
incompatibility, servers will have to offer at least one protocol that
works with every client, e.g. if you have any secure clients that are
DoT-only, then you have to offer DoT.

On Wed, Mar 10, 2021 at 9:31 PM Eric Rescorla <[email-masked]> wrote:

>> Tiru made an important point in the last minute of the ADD session
>> today.  A DNS intermediary attacker can synthesize a SVCB response for