Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)

[Tommy Pauly <[e-mail]>]

> On May 24, 2023, at 12:00 AM, tirumal reddy <[e-mail]> wrote:
> 
> On Wed, 24 May 2023 at 01:48, Tommy Pauly <tpauly=[e-mail] <mailto:[e-mail]>> wrote:
>> Using length=2 and INFO-CODE=0 sounds fine to me.
>> 
>> For the dependency on draft-ietf-add-resolver-info, I don't think we need to impose that dependency. I'd much prefer to allow clients to look at that optionally, but still be able to include the hint and use the extra text if it parses correctly.
> 
> Dependency on draft-ietf-add-resolver-info was added to address the threat where an attacker might inject (or modify) the EDE EXTRA-TEXT field with an DNS proxy or DNS forwarder that is unaware of EDE.More details are discussed in Section 10 of the draft. 

Using encrypted DNS to a known/trusted resolver can achieve this as well, so I think it is better as a recommendation of one way, but not a required way.

Tommy
> 
> Cheers,
> -Tiru
>  
>> 
>> Tommy
>> 
>>> On May 23, 2023, at 9:52 AM, Dan Wing <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> EDE length=2 with INFO-CODE=0 works nicely.
>>> 
>>> Also because non-EDE-aware DNS responders can be vulnerable to attacks described in Security Considerations, the Security Considerations section currently suggests clients use draft-ietf-add-resolver-info to check if server supports EDE. This needs better clarification in the document that client has to check draft-ietf-add-resolver-info before including EDE OPT in its DNS query. This check will further help interop by only sending EDE in requests to servers that indicated support via draft-ietf-add-resolver-info. However, it creates draft-ietf-add-resolver-info as another hurdle to deployment of Structured DNS error.  Thoughts?
>>> 
>>> (I also put the above text into our github issues; I don't know which folks prefer.  https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-structured-dns-error/issues/26)
>>> 
>>> -d
>>> 
>>> 
>>>> On May 22, 2023, at 7:44 PM, Tommy Pauly <tpauly=[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>> Thanks, Mark.
>>>> 
>>>> For what it's worth, I just ran two other tests, and for both of these cases, all of the resolvers I tried did accept the request:
>>>> - Choose a new EDNS option code point (I just tested 50, randomly)
>>>> - Use EDE but set the length to 2 and the error to 0 (other error), rather than a length of 0
>>>> 
>>>> Both of these seem viable, and I’ll let the authors and WG decide which is the right way forward.
>>>> 
>>>> Best,
>>>> Tommy
>>>> 
>>>>> On May 22, 2023, at 5:00 PM, Mark Andrews <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 23 May 2023, at 02:20, Tommy Pauly <tpauly=[e-mail] <mailto:[e-mail]>> wrote:
>>>>>> 
>>>>>> Hello DNSOP,
>>>>>> 
>>>>>> In draft-ietf-dnsop-structured-dns-error, there’s a description of how clients should indicate that they understand extended DNS errors (EDE) by sending an empty EDE option. 
>>>>>> 
>>>>>> https://www.ietf.org/archive/id/draft-ietf-dnsop-structured-dns-error-02.html#name-client-generating-request
>>>>>> 
>>>>>> This is something that makes a lot of sense to me, and provides a great way to indicate that a client would prefer to receive proper blocked/filtered errors (with possible extra text) as opposed to a forged answer.
>>>>>> 
>>>>>> However, in testing this out, I’m seeing inconsistent compatibility with some public resolvers. I was testing enabling this for encrypted resolvers only, and I see the following behavior for a sampling of resolvers using DoH:
>>>>>> 
>>>>>> 1.1.1.1 - NOERROR, works fine!
>>>>>> 9.9.9.9 - NOERROR, works fine!
>>>>>> 8.8.8.8 - FORMERR on all responses
>>>>>> dns.adguard-dns.com <http://dns.adguard-dns.com/> - SERVFAIL on all responses
>>>>>> 
>>>>>> Do we think that this should be allowed in queries (and thus this is a bug in resolvers like 8.8.8.8 or AdGuard)? Or is there a problem with the approach this document is suggesting?
>>>>> 
>>>>> RFC 8914 left whether EDE in requests was permitted or not undefined.  I can see an EDE implementation making the option parser return FORMERR if the EDE option length was less than 2 and applying that to both requests and responses.  RFC 8914 really should have said that EDE in requests should be ignored and then there would have been a possibility on extending behaviour based on adding EDE to a request.  We are already 10 years into trying to fix unknown EDNS option behaviour and are still getting FORMERR on unknown EDNS options in requests.  If the working group want to allow extending EDE by adding it to a request is should obsolete RFC 8914 now with RFC8914bis that specifies that EDE in requests are to be ignored.
>>>>> 
>>>>> At the moment draft-ietf-dnsop-structured-dns-error-02 really should use another EDNS option code point.  It really is not backwards compatible with EDE the way it is currently specified. 
>>>>> 
>>>>> 
>>>>>> Best,
>>>>>> Tommy
>>>>>> _______________________________________________
>>>>>> DNSOP mailing list
>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>>> 
>>>>> -- 
>>>>> Mark Andrews, ISC
>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>> PHONE: [phone]              INTERNET: [e-mail] <mailto:[e-mail]>
>>>>> 
>>>>> _______________________________________________
>>>>> DNSOP mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>> 
>>>> _______________________________________________
>>>> DNSOP mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/dnsop
>>> 
>>> _______________________________________________
>>> DNSOP mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/dnsop