From nobody Tue May 23 09:52:57 2023 Return-Path: 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 ; 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 ; 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 ; Tue, 23 May 2023 09:52:52 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-64d5f65a2f7so2192454b3a.1 for ; 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 Message-Id: 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: Cc: DNSOP WG To: Tommy Pauly References: <1BE5004E-B64D-407D-80F5-EB25D7BB671C@apple.com> <4A22932F-1980-438E-9B6A-176B82CECE50@isc.org> X-Mailer: Apple Mail (2.3731.600.7) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2023 16:52:56 -0000 --Apple-Mail=_32C9B361-BBFB-40C9-8D4A-621130854A6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 EDE length=3D2 with INFO-CODE=3D0 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/iss= ues/26) -d > On May 22, 2023, at 7:44 PM, Tommy Pauly = wrote: >=20 > Thanks, Mark. >=20 > 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 >=20 > Both of these seem viable, and I=E2=80=99ll let the authors and WG = decide which is the right way forward. >=20 > Best, > Tommy >=20 >> On May 22, 2023, at 5:00=E2=80=AFPM, Mark Andrews = wrote: >>=20 >>=20 >>=20 >>> On 23 May 2023, at 02:20, Tommy Pauly = wrote: >>>=20 >>> Hello DNSOP, >>>=20 >>> In draft-ietf-dnsop-structured-dns-error, there=E2=80=99s a = description of how clients should indicate that they understand extended = DNS errors (EDE) by sending an empty EDE option.=20 >>>=20 >>> = https://www.ietf.org/archive/id/draft-ietf-dnsop-structured-dns-error-02.h= tml#name-client-generating-request >>>=20 >>> 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. >>>=20 >>> However, in testing this out, I=E2=80=99m 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: >>>=20 >>> 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 >>>=20 >>> 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? >>=20 >> 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. >>=20 >> 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.=20 >>=20 >>=20 >>> Best, >>> Tommy >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>=20 >> --=20 >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org = >>=20 >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --Apple-Mail=_32C9B361-BBFB-40C9-8D4A-621130854A6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
EDE = length=3D2 with INFO-CODE=3D0 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-structur= ed-dns-error/issues/26)

-d


On May 22, 2023, at 7:44 PM, = Tommy Pauly <tpauly=3D40apple.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=E2=80=99ll let the authors and WG decide which is the right way = forward.

Best,
Tommy
On May 22, 2023, at 5:00=E2=80=AFPM, = Mark Andrews <marka@isc.org> wrote:



On 23 May 2023, at 02:20, Tommy Pauly = <tpauly=3D40apple.com@dmarc.ietf.org> wrote:

Hello = DNSOP,

In draft-ietf-dnsop-structured-dns-error, there=E2=80=99s = 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-gener= ating-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=E2=80=99= 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
https://www.ietf.org/= mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, = Australia
PHONE: +61 2 9871 4742 =             &n= bsp;INTERNET: marka@isc.org

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

_______________________________________________
DNS= OP mailing = list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
<= /div>

= --Apple-Mail=_32C9B361-BBFB-40C9-8D4A-621130854A6F--