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

[Mark Andrews <[e-mail]>]

> On 6 Mar 2024, at 08:19, Ben Schwartz <[e-mail]> wrote:
> 
> 
>> On Mar 5, 2024, at 4:02 PM, Mark Andrews <[e-mail]> wrote:
> 
>> Stop using +short and look at all of the response including whether aa is set or not in the flags. 
> 
> It is not set.  My complaint is that draft-ietf-add-resolver-info-11 doesn’t mention the AA bit at all.  It needs to instruct the client to inspect this bit, and reject the response if AA=0.

Yep.

> draft-11 still contains text about the record appearing in the Authority section, which could be equivalent to this, but that text is in a different section and its normative effect on the client is unclear.  I don’t object to that text, but I don’t think it’s sufficient as written, and I don’t think it’s necessary if the client is required to enforce AA=1.

That whole paragraph should be removed.

> —Ben
> 
>> 
>> --  
>> Mark Andrews
>> 
>>> On 6 Mar 2024, at 07:09, Ben Schwartz <[e-mail]> wrote:
>>> 
>>>  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
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]