From nobody Tue May 23 13:18:35 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 F2091C1519B6 for ; Tue, 23 May 2023 13:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=apple.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 0ZnMrk9TWHqH for ; Tue, 23 May 2023 13:18:30 -0700 (PDT) Received: from rn-mailsvcp-mx-lapp03.apple.com (rn-mailsvcp-mx-lapp03.apple.com [17.179.253.24]) (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 029F1C15155A for ; Tue, 23 May 2023 13:18:29 -0700 (PDT) Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by rn-mailsvcp-mx-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.22.20230228 64bit (built Feb 28 2023)) with ESMTPS id <0RV400K1DOEG4M20@rn-mailsvcp-mx-lapp03.rno.apple.com> for dnsop@ietf.org; Tue, 23 May 2023 13:18:29 -0700 (PDT) X-Proofpoint-GUID: EeS-9yGI753jQ46bl54dzwlIRygJY5vt X-Proofpoint-ORIG-GUID: EeS-9yGI753jQ46bl54dzwlIRygJY5vt X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.573, 18.0.957 definitions=2023-05-23_13:2023-05-23, 2023-05-23 signatures=0 X-Proofpoint-Spam-Details: rule=interactive_user_notspam policy=interactive_user score=0 malwarescore=0 mlxscore=0 mlxlogscore=999 suspectscore=0 adultscore=0 phishscore=0 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2304280000 definitions=main-2305230162 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=2MShF6D1mZvNxpseRZJ90I1NpIso+tHeVQkuZU1eadM=; b=kXe1NSL7Oklf3iLlGOG2perBBWbVJ9YRcTGWGTkvMd3SoXZZ6ymIYinYTHhmmbsiUdvB pwbm5XQYxuTZ7MbnK1wRaGTqChxgsSJ/Li1euHuLPmF5jEnlSXWOQOsIxYM4jTWDXQRL 3KtMoGG9QrKbS7RmdKBJtTfGh7+a6B+gciYblemPF4FnkRshHb+MHEP/yPds94UOL8cE o91x5gtXGLUjQ4p1lBRm4ELg0BvtCleFNPLJN21KwUOTkd4rRW7u/MwsAyLPz8cuyjRg 6jlXRYTVXbZhdl5HlPEbP/xY00nieR7PLMKlc+rRT3LcMvg7l1G6VnqrkD2LLmM7yy0f sg== Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.22.20230228 64bit (built Feb 28 2023)) with ESMTPS id <0RV4011ZVOEGFG50@rn-mailsvcp-mta-lapp01.rno.apple.com>; Tue, 23 May 2023 13:18:16 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.22.20230228 64bit (built Feb 28 2023)) id <0RV400X00O7ZZA00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 23 May 2023 13:18:16 -0700 (PDT) X-Va-A: X-Va-T-CD: e812c9238d6461ab0066b5d2f2d3d1f4 X-Va-E-CD: 0b79d2ebc82ccddf39c2a87c6a53fc06 X-Va-R-CD: d9006b4b5f3e35bccc03845f7ae332f2 X-Va-ID: f867c332-49a3-4d04-a4f9-6164e3875b84 X-Va-CD: 0 X-V-A: X-V-T-CD: e812c9238d6461ab0066b5d2f2d3d1f4 X-V-E-CD: 0b79d2ebc82ccddf39c2a87c6a53fc06 X-V-R-CD: d9006b4b5f3e35bccc03845f7ae332f2 X-V-ID: 88205b6c-ebde-45f1-9e3d-3b37b28d0d82 X-V-CD: 0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.573, 18.0.957 definitions=2023-05-23_12:2023-05-23, 2023-05-23 signatures=0 Received: from smtpclient.apple (unknown [17.230.171.162]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.22.20230228 64bit (built Feb 28 2023)) with ESMTPSA id <0RV400U7WOEESM00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 23 May 2023 13:18:15 -0700 (PDT) From: Tommy Pauly Message-id: <3255E1FA-0864-4BA6-A131-B478938714AE@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_DF10CE9F-172A-4E59-BEDA-E31738D7F9EB" MIME-version: 1.0 (Mac OS X Mail 16.0 \(3762.100.4.1.11\)) Date: Tue, 23 May 2023 13:18:04 -0700 In-reply-to: Cc: Tommy Pauly , DNSOP WG To: Dan Wing References: <1BE5004E-B64D-407D-80F5-EB25D7BB671C@apple.com> <4A22932F-1980-438E-9B6A-176B82CECE50@isc.org> X-Mailer: Apple Mail (2.3762.100.4.1.11) 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 20:18:34 -0000 --Apple-Mail=_DF10CE9F-172A-4E59-BEDA-E31738D7F9EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Using length=3D2 and INFO-CODE=3D0 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. Tommy > On May 23, 2023, at 9:52=E2=80=AFAM, Dan Wing = wrote: >=20 > EDE length=3D2 with INFO-CODE=3D0 works nicely. >=20 > 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? >=20 > (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) >=20 > -d >=20 >=20 >> 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 >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --Apple-Mail=_DF10CE9F-172A-4E59-BEDA-E31738D7F9EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Using = length=3D2 and INFO-CODE=3D0 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.

Tommy

On May 23, 2023, at 9:52=E2=80=AFAM, Dan Wing = <danwing@gmail.com> wrote:

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>

________________________________________= _______
DNSOP mailing = list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
<= /div>

= --Apple-Mail=_DF10CE9F-172A-4E59-BEDA-E31738D7F9EB--