Re: [Add] draft-ietf-add-resolver-info-09

[Ben Schwartz <[e-mail]>]

Mark's suggestion is correct, but I don't think draft-11 captures it correctly.  The draft-11 text only says

   The DNS client MUST set the Recursion
   Desired (RD) bit of the query to 0 to ensure that the response is provided by the resolver.
   If the resolver does not support RESINFO, it will return an authoritative name error.

This is factually incorrect, as can be observed by sending an RD=0 query to an ordinary recursive resolver:

% dig +short +norecurse www.google.com @1.1.1.1
142.251.167.104
142.251.167.147
142.251.167.99
142.251.167.106
142.251.167.103
142.251.167.105

Mark's suggestion is that the client verify that the response has AA=1.  That check ensures that the result was not populated insecurely over the network, but the draft doesn't mention it.

--Ben
________________________________
From: Add <[e-mail]> on behalf of [e-mail] <[e-mail]>
Sent: Wednesday, February 21, 2024 2:37 AM
To: Mark Andrews <[e-mail]>
Cc: tirumal reddy <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [Add] draft-ietf-add-resolver-info-09

!-------------------------------------------------------------------|
  This Message Is From an External Sender

|-------------------------------------------------------------------!

Hi Mark, all,

We think this is fair. Thanks.

We created a PR to fix this: https://github.com/boucadair/add-resolver-information/pull/19/files.

Cheers,
Tiru & Med

> -----Message d'origine-----
> De : Add <[e-mail]> De la part de Mark Andrews
> Envoyé : mercredi 21 février 2024 01:50
> À : Steffen Nurpmeso <[e-mail]>
> Cc : tirumal reddy <[e-mail]>; [e-mail]
> Objet : Re: [Add] draft-ietf-add-resolver-info-09
>
> If a recursive server passes through a response with AA=1 it is
> broken. If a recursive  server forwards a query with RD=0 it is
> broken.  If a “recursive server” is just forwarding queries and
> responses the attacker will just put the response in the authority
> section.  The change of section provides no security. It doesn’t
> prevent problems. It is just change for changes sake.
>
> --
> Mark Andrews
>
> > On 21 Feb 2024, at 06:30, Steffen Nurpmeso <[e-mail]>
> wrote:
> >
> > tirumal reddy wrote in
> > <CAFpG3gd5GwSAoOs3SX2xWZyKVR7F5y-
> [e-mail]>:
> > |On Thu, 15 Feb 2024 at 06:02, Mark Andrews <[e-mail]> wrote:
> > |> Why is it necessary to change the standard processing of queries
> > |> for RESINFO when we already have a signal (AA=1) about whether
> the
> > |> answer is coming from elsewhere or not ?
> > |
> > |It is introduced to handle a scenario where SUDN is used to
> discover
> > |the encrypted resolver, and if the discovered resolver does not
> > |support RESINFO, it will forward the query upstream. An attacker
> > |might provide a RESINFO response with AA=1. The proposed mechanism
> > |aims to help the client identify whether the response is coming
> from
> > |the discovered encrypted resolver.
> >
> > By the way i am really not worth being noted for anything
> > acknowledgeable regarding the work of this WG.  At all.
> > If you have another iteration of the document, i would prefer if you
> > would simply scratch my name from your work.
> > It is solely your work, for sure.
> > And the above is possibly very smart: my DNS work was two decades
> ago,
> > and i could not even tell whether i have ever seen authority section
> > entries being passed through or not.
> >
> > My main topics are simplicity so small teams can still exist
> > competetively as was true over two decades ago (ie, with knowing the
> > entire picture, not by delegating to "trusted" external modules in
> > uncounted numbers), when there were <3000 RFCs.
> >
> > As such i very much appreciated RFC 8499, but i alone from my
> > superficial out-of-interest reading have 17 DNS-related RFCs added
> > locally since then, plus the draft of yours and whatever else from
> > this WG.
> >
> > And a different way to get the TLS trust (or, rather, use existing
> > ways of various kind eg rpki, ikev2, or simply public keys as is
> done
> > by DKIM (certificates are a bit larger, but with the TCP that is
> more
> > and more needed per se, or QUIC; or even the permanent HTTP proxying
> > of everything, that is "no problem")) away from CA pools, to DNS/TLS
> +
> > DNSSEC zone records.  Thank you for that, too!
> >
> > Ciao, and greetings from Germany,
> >
> > --steffen
> > |
> > |Der Kragenbaer,                The moon bear,
> > |der holt sich munter           he cheerfully and one by one
> > |einen nach dem anderen runter  wa.ks himself off (By Robert
> > |Gernhardt)
>
> --
> Add mailing list
> [e-mail]
> https://eur03.safelinks.protection.outlook.com/?url=https://www .
> ietf.org%2Fmailman%2Flistinfo%2Fadd&data=05%7C02%7Cmohamed.boucadair%4
> 0orange.com%7C3a00adf00f6c4a88f66d08dc32770e24%7C90c7a20af34b40bfbc48b
> 9253b6f5d20%7C0%7C0%7C638440734117558876%7CUnknown%7CTWFpbGZsb3d8eyJWI
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7
> C%7C&sdata=GUI2%2FfrtBz%2FtYaA8ZmAGjR2jzb8mcp%2BmewuFjMiI3CE%3D&reserv
> ed=0
____________________________________________________________________________________________________________
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.
--
Add mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/add