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

Tommy Pauly <tpauly@apple.com> Tue, 23 May 2023 15:40 UTC

Return-Path: <tpauly@apple.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 7C0ABC14F736 for <dnsop@ietfa.amsl.com>; Tue, 23 May 2023 08:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 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_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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 h8WiLdmyVfwW for <dnsop@ietfa.amsl.com>; Tue, 23 May 2023 08:40:17 -0700 (PDT)
Received: from ma-mailsvcp-mx-lapp01.apple.com (ma-mailsvcp-mx-lapp01.apple.com [17.32.222.22]) (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 A3392C14EB19 for <dnsop@ietf.org>; Tue, 23 May 2023 08:40:17 -0700 (PDT)
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma-mailsvcp-mx-lapp01.apple.com (Oracle Communications Messaging Server 8.1.0.22.20230228 64bit (built Feb 28 2023)) with ESMTPS id <0RV40042UBJ33220@ma-mailsvcp-mx-lapp01.apple.com> for dnsop@ietf.org; Tue, 23 May 2023 08:40:16 -0700 (PDT)
X-Proofpoint-ORIG-GUID: kPG6BNEBMACLvZGqcFEinJWfkwdDOyI2
X-Proofpoint-GUID: kPG6BNEBMACLvZGqcFEinJWfkwdDOyI2
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.573, 18.0.942 definitions=2023-05-10_04:2023-05-05, 2023-05-10 signatures=0
X-Proofpoint-Spam-Details: rule=interactive_user_notspam policy=interactive_user score=0 bulkscore=0 mlxlogscore=999 adultscore=0 spamscore=0 phishscore=0 suspectscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2304280000 definitions=main-2305100143
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=tAZwcrKGYcinG8Ld4w/wshmtZopGeE5I5k4h+TPDXgI=; b=jB+Qq4LiefTMYqstaXxgL0gFRmfT/s7Uw+TMMrFRrG2agdDsKj/XBT0nBdV2iv0coDtl 9BKF+mgqiP+qYW6iN26hagJfaDIdHs+D6jkbg+X1F0pMU8KzFUISQeVCJ2JrN35GN1xp NYKndS/AkMHmcMO5FsMP0/zZ+36wd8EaE7wLyt3B4vwZE2WdvhI1Fkpin01s3vBlZ/+F HTBr4aHlWJqU9TMmoy7s+Q55/LkCSNmPKrpr9YW1cYo8NfBl9oyB/b7dpt6wEzb730Zt g/wdbaFim6znK+YILwFIOq+kS5LlqJKsk1msbeXRdvNWDGT72Bf5tLIOkMoHu89f7k4k jQ==
Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) 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 <0RV4006PKBJ3XQF0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Tue, 23 May 2023 08:40:15 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.22.20230228 64bit (built Feb 28 2023)) id <0RV400G00BI61O00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 23 May 2023 08:40:15 -0700 (PDT)
X-Va-A:
X-Va-T-CD: ee4c6c0660e4a98aa34d703cc3cd5142
X-Va-E-CD: 0b79d2ebc82ccddf39c2a87c6a53fc06
X-Va-R-CD: d9006b4b5f3e35bccc03845f7ae332f2
X-Va-ID: 96577285-373b-4093-b5d7-34e89075d5eb
X-Va-CD: 0
X-V-A:
X-V-T-CD: ee4c6c0660e4a98aa34d703cc3cd5142
X-V-E-CD: 0b79d2ebc82ccddf39c2a87c6a53fc06
X-V-R-CD: d9006b4b5f3e35bccc03845f7ae332f2
X-V-ID: e5424bb6-1faf-42f6-b503-c7323dd17d37
X-V-CD: 0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.573, 18.0.957 definitions=2023-05-23_10:2023-05-23, 2023-05-23 signatures=0
Received: from smtpclient.apple (unknown [17.230.171.162]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.22.20230228 64bit (built Feb 28 2023)) with ESMTPSA id <0RV400MFSBJ3QQ00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 23 May 2023 08:40:15 -0700 (PDT)
From: Tommy Pauly <tpauly@apple.com>
Message-id: <17343EB4-10EC-4968-9FCF-E950881B2017@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_7D77DEFD-BC84-4A0C-B658-CA7A27E0976E"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3762.100.4.1.11\))
Date: Tue, 23 May 2023 08:40:05 -0700
In-reply-to: <37179086-13A6-4840-BFCB-2C8349926AA2@isc.org>
Cc: Petr Špaček <pspacek@isc.org>, dnsop <dnsop@ietf.org>
To: Mark Andrews <marka@isc.org>
References: <1BE5004E-B64D-407D-80F5-EB25D7BB671C@apple.com> <4A22932F-1980-438E-9B6A-176B82CECE50@isc.org> <A474412D-191B-48BD-8FC4-E07578E9C487@apple.com> <70B7A79D-9419-45C9-A4F7-CA3BCB8CB4D9@fl1ger.de> <ef88a8d7-0c13-acff-a5fc-fdc0fb38de98@isc.org> <37179086-13A6-4840-BFCB-2C8349926AA2@isc.org>
X-Mailer: Apple Mail (2.3762.100.4.1.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/iDVy1i-te2EpOod37nnX3zPex5w>
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 15:40:21 -0000

To clarify, the point of the signal in the request is to indicate that the client knows how to handle EDE responses of filtered/blocked/etc.

When a resolver is filtering, it has to deal with both legacy clients and EDE-aware clients:
- For legacy clients, it will send a forged answer that sends a browser, etc, to a page that explains that they’re blocked. This technique is very problematic (breaks TLS cert trust, etc), but is very common, and unfortunately many resolvers won’t be willing to stop doing this for legacy clients.
- For clients that understand EDE for filtered/blocked etc, particularly if extra-text can be used, the resolver would instead prefer to use that mechanism. However, these EDE codes can’t be used with a forged answer, so the resolver needs to know the client understands how to deal with the errors in a sensible way.

Just using the OPT pseudo-RR isn’t enough — clients will include padding for DoH, etc, but still not know how to deal with EDE. So an explicit signal is preferable here.

Tommy

> On May 23, 2023, at 12:45 AM, Mark Andrews <marka@isc.org> wrote:
> 
> 
> 
>> On 23 May 2023, at 17:11, Petr Špaček <pspacek@isc.org> wrote:
>> 
>> On 23. 05. 23 7:03, Ralf Weber wrote:
>>> Moin!
>>> On 23 May 2023, at 4:44, Tommy Pauly 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
>>> I don’t think we need a new code point. Just having a valid opt record without a further option will work as RFC8914 states:
>>> The Extended DNS Error (EDE) option can be included in any response (SERVFAIL, NXDOMAIN, REFUSED, even NOERROR, etc.) to a query that includes an OPT pseudo-RR [RFC6891]. This document includes a set of initial codepoints but is extensible via the IANA registry defined and created in Section 5.2.
>>> and as the mechanism in draft-ietf-dnsop-structured-dns-error just defines a special format for the EDE EXTRA-TEXT field the most backward compatible solution IMHO is just to rely on the mechanism defined in RFC8914, and not to define any special handling.
>>> So I would propose 5.1 to be:
>>> When generating a DNS query, the client includes the OPT pseudo-RR [RFC6891] to elicit the Extended DNS Error option in the DNS response.
>> 
>> I agree. Sending empty EDE in requests seems superfluous to me.
> 
> The point of adding it to the request is to signal that that client will do the filtering.
> 
> Even if signalling is removed the current text is incompatible with EDE.  Read it in “perverse” mode (client will be stupid).
> 
>> -- 
>> Petr Špaček
>> Internet Systems Consortium
>> 
>> _______________________________________________
>> 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