Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)
Dan Wing <danwing@gmail.com> Tue, 23 May 2023 16:52 UTC
Return-Path: <danwing@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C919C1519AD for <dnsop@ietfa.amsl.com>; Tue, 23 May 2023 09:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxB7hqvdlRX9 for <dnsop@ietfa.amsl.com>; Tue, 23 May 2023 09:52:52 -0700 (PDT)
Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F81C1519AA for <dnsop@ietf.org>; Tue, 23 May 2023 09:52:52 -0700 (PDT)
Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-64d5f65a2f7so2192454b3a.1 for <dnsop@ietf.org>; Tue, 23 May 2023 09:52:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684860772; x=1687452772; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=ZtolXM8l9L4qH6hNLD4HesY1TSScbjGaJO0F3wdVNZo=; b=DT8y58qkNTFUzY6sYIQA4jXHp4qaROGUmJxIICiejomwg6PkMXor01N4gdMK7Wrv3F wWasuLp4Se/G/DuVSGSiEJBW8YsZno2SyBVvs87stcjtTQmuVijzJFXJ6dRLKDZpKFtc La43HeF3cuKYhLiLsYY6JM20WJc9E3OubLgEZqbuRXN/K23XbsdR9/3xRL2IJ/RwVC+3 WUriW3+o+cbyv99koCTtJKQ4dmb92EEjfe1flTYd/VmNyl6uHjLR95h4YLpo9X0wSohn 8AI8iT+lwal9Cq+++RISkcLITeVPIHoq4oN7NTgH5bE0HCabDdHCbzo/sf73ItIteFhS uTpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684860772; x=1687452772; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZtolXM8l9L4qH6hNLD4HesY1TSScbjGaJO0F3wdVNZo=; b=akFubYLwaaSwN3BAqMjuMP0jNlRLNZNhAs228hzVi+Fj/47avYq96Ze9XRU/t7GVMa PLOsuVUyrgLqRje9L+8vZJlAYT977C2ptMm0hLCc5CD288zMlW12dmUydL8I6RTFHyc3 gOlQnGUHE6w85gLkur5YqN3aMiDamDlvoyxvU8QpYOL+SHcHrwhq/9bb49EbnT4VqSBD 4B17P1xeXZ4WtouZjt2ZgozKWkkz2KE1KNDNWnpcn6V8yytN2NFjiJEbH/yI38a5pjrA /8V9ZIknLWDEEHdttJbU3c4twBZefRZ1/RQodSLMWlLAD57j30OKGgrZPzcaR/ew3iJT mTVw==
X-Gm-Message-State: AC+VfDy6pqV/A4WbtwYCItk1k9MnEzVd0Rz8yLRYdtlT4H40KaT8F+PI avYVuaIfmkBqI+xX8Hp76l3wE44dQyrYCA==
X-Google-Smtp-Source: ACHHUZ4ttkVIkK3hO5mcG931ko6DUpC+hMCRLB+BxhRhAS/9HwNxYMeGxu8GXwVPFBV/eoqrrCOosQ==
X-Received: by 2002:a05:6a00:2183:b0:647:1cb7:b714 with SMTP id h3-20020a056a00218300b006471cb7b714mr18091389pfi.3.1684860771463; Tue, 23 May 2023 09:52:51 -0700 (PDT)
Received: from smtpclient.apple ([47.208.218.46]) by smtp.gmail.com with ESMTPSA id a26-20020a62bd1a000000b0064f45b20703sm1269615pff.64.2023.05.23.09.52.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2023 09:52:50 -0700 (PDT)
From: Dan Wing <danwing@gmail.com>
Message-Id: <A79A4C21-43FD-4CC1-91C8-73F0F1C4BF28@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_32C9B361-BBFB-40C9-8D4A-621130854A6F"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Date: Tue, 23 May 2023 09:52:49 -0700
In-Reply-To: <A474412D-191B-48BD-8FC4-E07578E9C487@apple.com>
Cc: DNSOP WG <dnsop@ietf.org>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
References: <1BE5004E-B64D-407D-80F5-EB25D7BB671C@apple.com> <4A22932F-1980-438E-9B6A-176B82CECE50@isc.org> <A474412D-191B-48BD-8FC4-E07578E9C487@apple.com>
X-Mailer: Apple Mail (2.3731.600.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/yUw__U4rd2ksTTtFyBiMSvrG60U>
Subject: Re: [DNSOP] Incompatibility with indicating client support for EDE (draft-ietf-dnsop-structured-dns-error)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 May 2023 16:52:56 -0000
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=40apple.com@dmarc.ietf.org> 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 <marka@isc.org> wrote: >> >> >> >>> On 23 May 2023, at 02:20, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> 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 - 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 >>> DNSOP@ietf.org <mailto:DNSOP@ietf.org> >>> https://www.ietf.org/mailman/listinfo/dnsop >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org <mailto:marka@isc.org> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org <mailto:DNSOP@ietf.org> >> https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
- [DNSOP] Incompatibility with indicating client su… Tommy Pauly
- Re: [DNSOP] Incompatibility with indicating clien… Ralf Weber
- Re: [DNSOP] Incompatibility with indicating clien… Mark Andrews
- Re: [DNSOP] Incompatibility with indicating clien… Tommy Pauly
- Re: [DNSOP] Incompatibility with indicating clien… Petr Špaček
- Re: [DNSOP] Incompatibility with indicating clien… Ralf Weber
- Re: [DNSOP] Incompatibility with indicating clien… Mark Andrews
- Re: [DNSOP] Incompatibility with indicating clien… Ralf Weber
- Re: [DNSOP] Incompatibility with indicating clien… Tommy Pauly
- Re: [DNSOP] Incompatibility with indicating clien… Dan Wing
- Re: [DNSOP] Incompatibility with indicating clien… Tommy Pauly
- Re: [DNSOP] Incompatibility with indicating clien… Ralf Weber
- Re: [DNSOP] Incompatibility with indicating clien… tirumal reddy
- Re: [DNSOP] Incompatibility with indicating clien… Tommy Pauly
- Re: [DNSOP] Incompatibility with indicating clien… tirumal reddy